GNOME Bugzilla – Bug 352271
Location of G_GNUC_INTERNAL breaks Solaris build
Last modified: 2010-01-24 01:07:09 UTC
gimp makes uses of the G_GNUC_INTERNAL macro. For the Solaris forte compiler this must be placed at the start of the line. Can you please apply the attached patch - it moves the macro 16 times. This will not affect gcc - it does not care where the macro is placed. See also 350606 (gtk-engines) and 352981 (glib). 350606 has a link to a cairo change where they resolved this issue with a private macro.
Created attachment 71322 [details] [review] Move G_GNUC_INTERNAL to the start of the line.
Go, go, Solaris magic.
solaris forte compiler is not gnu. our G_GNUC_* usage is OK, glib has to be fixed so that this macro are expanded to nothing with solaris forte. i'm against this commit.
If we can move a macro and enable it to work with more compilers, I don't see what the problem is. Regardless of where they come from. Obviously we would never want to break gcc, but anything else we can have is a bonus.
Obviously, G_GNUC_ is for GNUC. Glib has to be fixed.
I've commited this patch, since the patch is marked approved for commit. GNUC doesn't care whether the macro is at the beginning or end of the prototype so this will not break anything and the usage at the beginning of the proto is more standard (used in Xorg code for example). I agree that we probably should create new non-GCC macro in the glib code and use those instead. Or perhaps doing something like what cairo does and use its own macros instead of using the problematic Glib ones would be a better approach. http://gitweb.freedesktop.org/?p=cairo;a=blobdiff;h=9d1c789d2209aab3f969cc1e6baef5a997826e85;hp=447c1ac0bb8fba938495c26abefaecb3e1f87f78;hb=04757a3aa8deeff3265719ebe01b021638990ec6;f=src/cairoint.h I'm happy to rework the patch so gnome-applets uses its own macro like this instead if that makes people happier.
(In reply to comment #6) > I've commited this patch, since the patch is marked approved for commit. GNUC > doesn't care whether the macro is at the beginning or end of the prototype > so this will not break anything and the usage at the beginning of the proto > is more standard (used in Xorg code for example). i don't get why sun forte cares. Please open a bug against glib.
Benoit: it is not the _macro_, but the _location_ of the macro which is the problem. Please check the patch closely. It changes the _location_ of the macro. There is nothing wrong with the patch. G_GNUC_* is indeed for gcc extensions, however, this does not prevent other compilers from implementing similar behaviour using compatible indicators. The glib documentation could probably be changed to indicate that the macro should be used in the beginning, not at the end, of functions. However, the above patch is still valid.
Refer here for glib bug on this issue: http://bugzilla.gnome.org/show_bug.cgi?id=342981 Note bug number is wrong in Damien's original comment #1. Our hope is that if we can get the various modules that use this macro to conform to the "use before the proto" standard, that we can make progress with the above bug. It seems that the glib maintainers are not eager to change this without seeing some support from the other modules that this change is a good move. It's really a minor change and makes the code easier to compile properly on more compilers without needing to patch the code. Exactly the same reason why the Xorg macros are done this way already.
OK ... i just disagree on G_GNUC_* being recycled for !gcc. What if my compiler requires the following "void G_GNUC_INTERNAL foo(int)" ? Btw, i guess it would be better to fix all these issues by using gcc 4 visibility command line args and/or provide a list of public symbols (glib does that i think). pragma are a good solution too. I feel paranoïd but G_GNUC_INTERNAL has a noticeable effect even on program (not only on shared object) : code size reduction. Tagging every symbol as internal seems stupid.
A Glib bug should be opened to discuss this matter in further detail, since we can't effect any change here.