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 374730 - Location of G_GNUC_INTERNAL breaks Solaris build
Location of G_GNUC_INTERNAL breaks Solaris build
Status: RESOLVED DUPLICATE of bug 342981
Product: glib
Classification: Platform
Component: general
unspecified
Other Solaris
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks: 373041
 
 
Reported: 2006-11-13 15:52 UTC by Damien Carbery
Modified: 2006-11-23 10:05 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
Define G_GNUC_INTERNAL for Solaris and move macro to start of line when used (6.99 KB, patch)
2006-11-13 15:54 UTC, Damien Carbery
none Details | Review

Description Damien Carbery 2006-11-13 15:52:55 UTC
glib defines and uses the G_GNUC_INTERNAL macro. For the Solaris forte compiler the macro must be placed at the start of the line

Can you please apply the attached patch - it moves the macro in the 2
instances.
This will not affect gcc - it does not care where the macro is placed.

Other modules have already moved the macro: libgnomeui (bug 352274), gnome-applets (bug 352271), GIMP (bug 352268), gtk-engines (350606).
Comment 1 Damien Carbery 2006-11-13 15:54:08 UTC
Created attachment 76492 [details] [review]
Define G_GNUC_INTERNAL for Solaris and move macro to start of line when used
Comment 2 Benoît Dejean 2006-11-16 13:27:03 UTC
I'd like the glib doc to clearly state :
- where G_GNUC_ macro have to be : before or after declaration. Currently it says to follow GCC documentation.
- if it is expected that non GNU C compiler implement these macro. If yes, then their names are misleading.

We can't just move macros intented to be GCC only to please one's compiler because it may break other compilers support.

May be the best would be to have portable pragma instead of these visibility macros.
Comment 3 Damien Carbery 2006-11-16 14:20:42 UTC
Benoît and I have different viewpoints on this. AFAIK he is concerned that moving the macro will break other compilers. I am confident that it doesn't, as 4 other modules have moved the macro to the top of the line, done a few tarball releases and not moved it back again. Therefore I am assuming that it does not break the build and won't here (or in system-monitor bug 373041).

The macro is coded to only be defined for gcc and Solaris Forte compilers. We know both of those support it (though forte wants it at the top of the line, gcc doesn't care). As it is not defined for other compilers it does not matter what they support.
Comment 4 Benoît Dejean 2006-11-16 14:49:22 UTC
I am concerned that one day some compiler (maybe even gcc) requires us to move back the G_GNUC after declaration.

> The macro is coded to only be defined for gcc and Solaris Forte compilers. We
> know both of those support it (though forte wants it at the top of the line,
> gcc doesn't care). As it is not defined for other compilers it does not matter
> what they support.

G_GNUC_ was only defined for GCC (__GNUC__) and only meant for GCC. Now Forte. Which compiler is next ? AIX ? MSC++ ?

My code does legal glib usage. I think your patch extends G_GNUC_* in an unepextected, restrictive and breaking way. I'm waiting the glib to tell me exactly where to put these macros. Or also provide a patch to update the documentation.
Comment 5 Brian Cameron 2006-11-17 03:59:58 UTC
Isn't this bug a duplicate of #342981?

I do think that the naming of this macro sucks.  Note in the above bug that Xorg, and cairo also use similar macros and define the macro at the beginning and not the end.  This seems to be the standard way that modules make hidden work.  

Probably should deprecate the G_GNUC macro and start using a new macro that doesn't have "GNUC" in it's name.

But moving it to the beginning doesn't break anything for GCC since it doesn't care about the placement.  So if we aren't willing to move to using a new macro, why not just move the placement so it is consistant with the way it is used by Xorg, cairo, etc.?



Comment 6 Damien Carbery 2006-11-23 10:05:22 UTC

*** This bug has been marked as a duplicate of 342981 ***