GNOME Bugzilla – Bug 445362
Non-numeric local labels in gatomic.c are causing linker errors
Last modified: 2008-01-06 23:10:22 UTC
Attempting to build GLib 2.12.x on OS X 10.{I could tell you but I'd have to kill you :-)} got "bc out of range (352768 max is +/-64K)" errors from the linker. The linker person to whom I reported this said The use of .L prefix for labels is an ELF thing. On Mac OS X you use just L prefix. The cross platform way to do this is numbered labels and have the branches use the 'b' or 'f' suffix for back or forward. although, unfortunately, that's not cross-platform enough, as, according to another GLib bug, that *doesn't* work on AIX, as it doesn't support numbered labels.
Interesting! I know that several recent glib-2.12.x build on "many different OS X 10.x versions". I wonder if you have some certain platform difference (hardware and software details would be good) vs other folks such that only yours triggers inclusion of the asm code? Are you setting any special flags manually? Which asm chunks are giving this error? Maybe glib needs a configure test to determine what style of label is correct for the local machine, and propagate that via a config.h token or a flag there that chooses among several different implementations in gatomic.c? Assuming you're talking about what I think you're talking about, probably not much more you can say here, but I'm seeded and would be interested in hearing more details via email. I assume the AIX issue is Bug #316434 ? Is there a Radar# for your discussion with "The linker person"?
The asm segments here are wrapped in #ifdef __OPTIMIZE__ (there are pure-C implementations for non-optimized builds, for example, CFLAGS=-O0). I wonder if it would be generally useful to combine that test with the results of an optional --disable-asm configure flag, so that one doesn't have to turn off all of gcc's own optimizations just to disable the assembly-code chunks.
Please see also Bug 491990 which seems to be the same problem but a different proposed solution.
Wonder if the portable solution to using the "right kind of" local labels is a configure test? Something like: AC_TRY_COMPILE(,[ something with undotted local labels ], AC_TRY_COMPILE(,[ same thing but with dotted local labels ], AC_DEFINE(ASM_DOT_PREFIX_LOCAL_LABEL, 1)) and then gatomic.c could do: #if ASM_DOT_PREFIX_LOCAL_LABEL #define ASM_PREFIX . #else #define ASM_PREFIX #endif and use that macro instead of the actual leading dot in the __asm__ blocks. I don't have access to OS X on a 64-bit machine nor to AIX to test these cases, but if this looks like a useful solution I'd be happy to write a patch for some actual code.
Reading about the change (svn revision #5081) and Bug #316434 that led to it, seems like numbered labels is the way to go "in all cases where it works". The cases where it doesn't work (AIX), using numbered labels is a compiler error, and falling back to .Lnumnum is the solution. So even better than my Comment #4 check for dots, could test for numbered labels. Or at worst, just match host_os against *aix* (thanks pogma!) or even check a hostname token in gatomic.c itself.
if you could try to come up with a patch for this, that would be really appreciated.
Created attachment 98753 [details] [review] Check whether assembler supports numerical local labels First whack at this. The changes at issue are only in the POWERPC blocks, so I confined the test to the block that decides to use that POWERPC code. I don't know ppc assembly, so the actual test is just a cut'n'paste trial'n'error from gatomic.c itself. Confirmed that this configure test gives the expected results on aix/powerpc gcc (AC_TRY_COMPILE fails) and on darwin/powerpc OS X 10.3 gcc (AC_TRY_COMPILE succeeds).
Guy, Ryan, can you try the patch ? I don't have any powerpc machines at hand to test this on.
autoreconf doesn't want to make configure out of configure.in on my Leopard machine - I keep getting complaints, and keep trying to squish them. Right now, I get $ autoreconf --warnings=none gtk-doc.make:7: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL docs/reference/glib/Makefile.am:68: `gtk-doc.make' included from here gtk-doc.make:43: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL docs/reference/glib/Makefile.am:68: `gtk-doc.make' included from here gtk-doc.make:136: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL docs/reference/glib/Makefile.am:68: `gtk-doc.make' included from here gtk-doc.make:7: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL docs/reference/gobject/Makefile.am:56: `gtk-doc.make' included from here gtk-doc.make:43: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL docs/reference/gobject/Makefile.am:56: `gtk-doc.make' included from here gtk-doc.make:136: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL docs/reference/gobject/Makefile.am:56: `gtk-doc.make' included from here autoreconf: automake failed with exit status: 1 The versions in 10.5.0 are $ autoconf --version autoconf (GNU Autoconf) 2.61 Copyright (C) 2006 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law. Written by David J. MacKenzie and Akim Demaille. $ automake --version automake (GNU automake) 1.10 Written by Tom Tromey <tromey@redhat.com> and Alexandre Duret-Lutz <adl@gnu.org>. Copyright 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. If you could regenerate the configure script and attach that, or add a patch for it, that would be ideal.
Created attachment 98824 [details] [review] configure patch
The configure script patch worked (after editing config.h.in to tell it about the new option), so this change seems to be the right answer.
2007-11-18 Matthias Clasen <mclasen@redhat.com> * configure.in: Check whether assembler supports numerical local labels. * glib/gatomic.c: Fix powerpc implementation of atomic ops for platforms where the assembler doesn't support numerical local labels. (#445362)
*** Bug 491990 has been marked as a duplicate of this bug. ***