GNOME Bugzilla – Bug 315437
extern inline -> static inline
Last modified: 2008-03-31 18:20:21 UTC
I noticed that the kernel janitors are doing this cleanup so I thought we would like to do the same? :-) I think this might fix a warning from sparse that I didn't understand earlier.
Created attachment 51912 [details] [review] proposed patch
Nah, don't mess with the inline stuff there. I only causes trouble.
Actually, this change (or something similar) is going to be necessary when GCC supports C99's 'extern inline' properly when in -std=c99 or std=gnu99 mode, as per this patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00328.html
See: http://bugs.gentoo.org/show_bug.cgi?id=156475 GCC4.3 Alphas change to "extern inline" breaks glib(2.12) , but the work around is pretty simple.
Here's an upstream GCC bug on the subject: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31389 My reading is that G_INLINE_FUNC should simply be "inline", and not "static inline". Can anyone confirm this works as expected? I don't have access to GCC 4.3 builds ATM.
This becomes pressing as gcc 4.3 is drawing near; perhaps it's time to pull the change in the next dev release?
Created attachment 90083 [details] [review] Use __inline with gcc plus __attribute__ ((__gnu_inline__)) for gcc 4.3 in C99 mode Patch adapted from this version and the version found in the Gentoo bug which I included in the Debian package. I confirmed it fixes some build failures which happened without the patch, such as the one reported here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416863 (Note: the package fails to build due to a couple missing includes of <locale.h> later on) I diffed two glib builds with and without the patch, and the build logs does not expose more warnings / errors.
+1 Without this patch, pygtksourceview build is broken (same gutils.h inlined functions errors), it uses '-std=c9x' by default. I would raise the priority of this patch by confirming the bug to NEW.
The fix has been backported to gcc 4.2.1. So __GNUC_PREREQ (4,3) should be changed to __GNU_PREREQ (4,2) (or maybe __GNU_PREREQ (4,2,1) if that works). By doing that change I was able to build a package that used c99 and glib that gcc 4.2.1 otherwise failed on.
*** Bug 388184 has been marked as a duplicate of this bug. ***
Created attachment 96366 [details] [review] Use __inline with gcc plus __attribute__ ((__gnu_inline__)) for gcc 4.2 in C99 mode Update check to __GNUC_PREREQ (4,2) (didn't check whether __GNUC_PREREQ (4,2,1) works)
(In reply to comment #11) > Created an attachment (id=96366) [edit] > Use __inline with gcc plus __attribute__ ((__gnu_inline__)) for gcc 4.2 in C99 > mode > > Update check to __GNUC_PREREQ (4,2) (didn't check whether __GNUC_PREREQ (4,2,1) > works) looking into this, i'd like to ensure that gnu_inline is really what we want in the glib context here.
*** Bug 484460 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > (In reply to comment #11) > > Created an attachment (id=96366) [edit] > > Use __inline with gcc plus __attribute__ ((__gnu_inline__)) for gcc 4.2 in C99 > > mode > > > > Update check to __GNUC_PREREQ (4,2) (didn't check whether __GNUC_PREREQ (4,2,1) > > works) > > looking into this, i'd like to ensure that gnu_inline is really what we want in > the glib context here. I think it is very safe to assume that. This is the exact same change that many other projects are applying.
Fink users on the just-released Leopard (OS X 10.5) have reported bugs compiling things that use glib2 that appear to be traceable back to this same inline issue. Not sure what I can do to help get this fixed.
(In reply to comment #15) > Fink users on the just-released Leopard (OS X 10.5) have reported bugs > compiling things that use glib2 that appear to be traceable back to this same > inline issue. Not sure what I can do to help get this fixed. Indeed, this hits the native glib/gtk+ port as well, I have solved it for now by building everything with -std=gnu89, since 99 is the default in 10.5...
OS X doesn't appear to have __GNUC_PREREQ (being a non-glibc platform), so we'll need to define it ourselves (protected by #ifndef) if attachment (id=96366) is the way to solve this.
Created attachment 98457 [details] [review] define GNUC_PREREQ if it's not already available It gets weirder...OS X Leopard is gcc-4.0.1, and it's already giving bad handling of the glib inline functions using -std=c9x (default on pygobject, libglade, etc). RangerRick and I fiddled with various permutations of gcc prereq handling in attachment (id=96366) and were never able to get pygobject to compile: ld: duplicate symbol _g_bit_nth_lsf in .libs/_gobject_la-pygboxed.o and .libs/_gobject_la-gobjectmodule.o
This bug is starting to cause build failures for projects that use -Werror, such as gnome-vfs - see bug 474656 - or swfdec, because gcc-4.2 throws warnings about broken glib headers with -Wall. Can we get this fixed as soon as possible, please?
with all this gcc-ism discussion here... is there any reason to not simply use "static inline" for the gcc case as well? after all, it works fine for all other compilers.
Changing extern inline to extern __inline on OS X Leopard with gcc 4.0.1 does not fix compilation of glib 2.14.3 for me, neither does using static inline: ld: bc out of range (486044 max is +/-64K) from _g_atomic_int_exchange_and_add in .libs/gatomic.o to _g_atomic_int_exchange_and_add$stub in .libs/libglib-2.0.0.1400.3.dylib in _g_atomic_int_exchange_and_add from .libs/gatomic.o collect2: ld returned 1 exit status make[4]: *** [libglib-2.0.la] Error 1 For a binary glib 2.14.0 compiled on Tiger, changing the header to static inline was the only way I could make linking work on Leopard.
(In reply to comment #21) > Changing extern inline to extern __inline on OS X Leopard with gcc 4.0.1 does > not fix compilation of glib 2.14.3 for me, neither does using static inline: > ld: bc out of range (486044 max is +/-64K) from _g_atomic_int_exchange_and_add > in .libs/gatomic.o to _g_atomic_int_exchange_and_add$stub in > .libs/libglib-2.0.0.1400.3.dylib in _g_atomic_int_exchange_and_add from As far as I can see, that is unrelated to this bug (looks more like http://bugzilla.gnome.org/show_bug.cgi?id=445362).
*** Bug 504039 has been marked as a duplicate of this bug. ***
*** Bug 474656 has been marked as a duplicate of this bug. ***
Any progress?
I've applied the patch in comment #18 to fix build issues for now, while we are mulling over extern vs static inline...
(In reply to comment #26) > I've applied the patch in comment #18 to fix build issues for now, while we are > mulling over extern vs static inline... again, is there any reason to not simply use "static inline" which works fine for all other compilers? so far, no reason has been presented to preserve the gcc special casing.
from all i could read up on the issue, there doesn't seem to be any benefit of extern-inline/gnu_inline over "static inline" for the scope of glib. so the following commit should settle the issue. 2008-01-18 16:51:23 Tim Janik <timj@imendio.com> * glib/gutils.h: don't define __GNUC_PREREQ which is not in the glib namespace. for gcc, define G_INLINE_FUNC to "static inline" as with all other C compilers, because newer GCC versions incompatibly changed "extern inline" semantics.
The piece of gutils.h, as it exists in glib 2.16.1 does not work with Mac OS X 10.5.2. I have to force # define G_INLINE_FUNC static inline in order for some things (e.g. pygobject) to compile.
(In reply to comment #29) > The piece of gutils.h, as it exists in glib 2.16.1 does not work with Mac OS X > 10.5.2. I have to force > # define G_INLINE_FUNC static inline > in order for some things (e.g. pygobject) to compile. can you be more specific? like, what error message are you getting when compiling which component?
when compiling pygobject 2.14.1 with glib 2.16.1 already installed (with the fink patches except the one regarding the inline function definition), I get: gcc ${wl}-undefined ${wl}dynamic_lookup -o .libs/_gobject.so -bundle .libs/_gobject_la-gobjectmodule.o .libs/_gobject_la-pygboxed.o .libs/_gobject_la-pygenum.o .libs/_gobject_la-pygflags.o .libs/_gobject_la-pygobject.o .libs/_gobject_la-pygmaincontext.o .libs/_gobject_la-pygmainloop.o .libs/_gobject_la-pygparamspec.o .libs/_gobject_la-pygpointer.o .libs/_gobject_la-pygiochannel.o .libs/_gobject_la-pygsource.o .libs/_gobject_la-pygtype.o .libs/_gobject_la-pygoptioncontext.o .libs/_gobject_la-pygoptiongroup.o -L/sw/lib /sw/lib/libgobject-2.0.dylib /sw/lib/libgthread-2.0.dylib /sw/lib/libglib-2.0.dylib /sw/lib/libintl.dylib /sw/lib/libiconv.dylib -Wl,-exported_symbols_list,.libs/_gobject-symbols.expsym ld: duplicate symbol _g_bit_nth_lsf in .libs/_gobject_la-pygboxed.o and .libs/_gobject_la-gobjectmodule.o collect2: ld returned 1 exit status make[2]: *** [_gobject.la] Error 1 If I run nm -g on both those libraries, 00000000 T _g_bit_nth_lsf shows up in both. The additional patch to glib 2.16.1 that allows pygobject to complete building is: diff -Nurd glib-2.16.1orig/glib/gutils.h glib-2.16.1new/glib/gutils.h --- glib-2.16.1orig/glib/gutils.h 2008-03-10 20:31:56.000000000 -0400 +++ glib-2.16.1new/glib/gutils.h 2008-03-19 00:09:10.000000000 -0400 @@ -97,11 +97,7 @@ # define G_INLINE_FUNC # undef G_CAN_INLINE #elif defined (__GNUC__) -# ifdef __GNUC_STDC_INLINE__ -# define G_INLINE_FUNC extern inline __attribute__ ((__gnu_inline__)) -# else -# define G_INLINE_FUNC extern inline -# endif +# define G_INLINE_FUNC static inline #elif defined (G_CAN_INLINE) # define G_INLINE_FUNC static inline #else /* can't inline */
(In reply to comment #31) > The additional patch to glib 2.16.1 that allows pygobject to complete building > is: > diff -Nurd glib-2.16.1orig/glib/gutils.h glib-2.16.1new/glib/gutils.h > --- glib-2.16.1orig/glib/gutils.h 2008-03-10 20:31:56.000000000 -0400 > +++ glib-2.16.1new/glib/gutils.h 2008-03-19 00:09:10.000000000 -0400 > @@ -97,11 +97,7 @@ > # define G_INLINE_FUNC > # undef G_CAN_INLINE > #elif defined (__GNUC__) > -# ifdef __GNUC_STDC_INLINE__ > -# define G_INLINE_FUNC extern inline __attribute__ ((__gnu_inline__)) > -# else > -# define G_INLINE_FUNC extern inline > -# endif > +# define G_INLINE_FUNC static inline > #elif defined (G_CAN_INLINE) > # define G_INLINE_FUNC static inline > #else /* can't inline */ thanks, the static inline variant should have stayed in glib in the first place, fixed again in revision 6789.
static inline is not right
(In reply to comment #33) > static inline is not right what's wrong about it? we've been using it since the inception of glib inline functions on all platforms other than gcc. for gcc we allowed the optimization of "extern inline", but recent versions stoped providing macro-like semantics for extern inline, so that's the case for using "static inline" for gcc as well. (and no problem has been reported for "static inline" so far.)