GNOME Bugzilla – Bug 492152
On Mac OS X Leopard #define G_INLINE_FUNC as static inline
Last modified: 2018-05-24 11:09:12 UTC
Please describe the problem: On Mac OS X (Leopard) G_INLINE_FUNC is defined as extern inline. This is the cause of symbol duplication with an error message like: ld: duplicate symbol _g_bit_nth_lsf in jpilot-sync.o and category.o g_bit_nth_lsf is defined as: #if defined (G_CAN_INLINE) || defined (__G_UTILS_C__) G_INLINE_FUNC gint g_bit_nth_lsf (gulong mask, gint nth_bit) { [...] G_INLINE_FUNC is defined as: #ifdef G_IMPLEMENT_INLINES # define G_INLINE_FUNC # undef G_CAN_INLINE #elif defined (__GNUC__) # define G_INLINE_FUNC extern inline #elif defined (G_CAN_INLINE) # define G_INLINE_FUNC static inline #else /* can't inline */ # define G_INLINE_FUNC #endif /* !G_INLINE_FUNC */ Even if Mac OS X uses GCC as the compiler the linker is _not_ GNU ld. $ ld -v @(#)PROGRAM:ld PROJECT:ld64-77 Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information: I propose the patch: Index: glib/glib/gutils.h =================================================================== --- glib/glib/gutils.h (revision 5798) +++ glib/glib/gutils.h (working copy) @@ -96,10 +96,10 @@ G_BEGIN_DECLS #ifdef G_IMPLEMENT_INLINES # define G_INLINE_FUNC # undef G_CAN_INLINE -#elif defined (__GNUC__) -# define G_INLINE_FUNC extern inline #elif defined (G_CAN_INLINE) # define G_INLINE_FUNC static inline +#elif defined (__GNUC__) +# define G_INLINE_FUNC extern inline #else /* can't inline */ # define G_INLINE_FUNC #endif /* !G_INLINE_FUNC */ Maybe adding a #ifdef __APPLE__ would be a better idea.
Please see Bug #491990, which has been working on this approach to this issue for a while now.
Or more properly, Bug #445362 (491990 is a different kind of solution to this problem)
I am not sure it is the same problem as in Bug #445362. Defining G_INLINE_FUNC as "static inline" instead of "extern inline" DOES solve the problem for me. The linker complains because the same symbol is defined in two .o files. If the function is declared "static" instead of "extern" the function symbol will not be exported outside of the .o file and the linker will be happy. The side effect of my solution is that the same code is present in two (or more) .o files. But that is the exact goal of inline functions, isn't it?
Aw heck, trying to track too many Leopardish bugs at once:( The previous inline issue is Bug #315437
Here's the MacPorts solution: http://trac.macports.org/projects/macports/attachment/ticket/13006/glib2-inline.patch
I can confirm this bug on 10.5 for svn 6147. The MacPorts patch seems to fix it.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/112.