After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 492152 - On Mac OS X Leopard #define G_INLINE_FUNC as static inline
On Mac OS X Leopard #define G_INLINE_FUNC as static inline
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2007-10-31 20:23 UTC by Ludovic Rousseau
Modified: 2018-05-24 11:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ludovic Rousseau 2007-10-31 20:23:06 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.
Comment 1 Daniel Macks 2007-11-01 01:21:35 UTC
Please see Bug #491990, which has been working on this approach to this issue for a while now.
Comment 2 Daniel Macks 2007-11-01 01:22:16 UTC
Or more properly, Bug #445362 (491990 is a different kind of solution to this problem)
Comment 3 Ludovic Rousseau 2007-11-01 08:37:22 UTC
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?
Comment 4 Daniel Macks 2007-11-02 05:11:37 UTC
Aw heck, trying to track too many Leopardish bugs at once:( The previous inline issue is Bug #315437
Comment 5 Daniel Macks 2007-11-02 05:14:57 UTC
Here's the MacPorts solution: http://trac.macports.org/projects/macports/attachment/ticket/13006/glib2-inline.patch
Comment 6 pat2man 2007-12-17 23:29:39 UTC
I can confirm this bug on 10.5 for svn 6147. The MacPorts patch seems to fix it.
Comment 7 GNOME Infrastructure Team 2018-05-24 11:09:12 UTC
-- 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.