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 373041 - Location of G_GNUC_INTERNAL breaks Solaris build
Location of G_GNUC_INTERNAL breaks Solaris build
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: general
2.17.x
Other Solaris
: Normal major
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
Depends on: 374730
Blocks:
 
 
Reported: 2006-11-09 17:16 UTC by Damien Carbery
Modified: 2011-11-11 10:03 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
Move G_GNUC_INTERNAL to start of line to build on Solaris (20.39 KB, patch)
2006-11-09 17:17 UTC, Damien Carbery
none Details | Review

Description Damien Carbery 2006-11-09 17:16:51 UTC
gnome-system-monitor makes extensive use 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 this does this 91 times for various
gnome-system-monitor files.
This will not affect gcc - it does not care where the macro is placed.
Comment 1 Damien Carbery 2006-11-09 17:17:37 UTC
Created attachment 76288 [details] [review]
Move G_GNUC_INTERNAL to start of line to build on Solaris
Comment 2 Damien Carbery 2006-11-09 17:18:18 UTC
This is compiler safe - see discussion with gtk-engines at http://bugzilla.gnome.org/show_bug.cgi?id=350606
Comment 3 Benoît Dejean 2006-11-10 11:03:10 UTC
I was part of that discussion and haven't change my mind. I don't expect a compiler that is not the GNU compiler to expand G_GNUC macros. That's what the documentation says.

G_GNUC_INTERNAL

#define G_GNUC_INTERNAL __attribute__((visibility("hidden")))

Expands to the GNU C visibility(hidden) attribute if the compiler supports it (currently only gcc). This attribute can be used for marking library functions as being used internally to the lib only, to not create inefficient PLT entries. Note that static functions do not need to be marked as internal in this way. See the GNU C documentation for details. 
Comment 4 Damien Carbery 2006-11-10 11:09:08 UTC
"currently only gcc" - that is an inaccurate statement. Forte supports it, but it needs to have it placed at the start of the line.
Comment 5 Benoît Dejean 2006-11-13 10:07:31 UTC
Then the other guy from AIX comes to me 'Location of G_GNUC_INTERNAL breaks AIX build' requesting G_GNUC_INTERNAL to be at end of declaration...
Comment 6 Damien Carbery 2006-11-13 15:17:12 UTC
AIX? They still make that ;)

gtk-engines (bug 350606), GIMP (bug 352268), gnome-applets (bug 352271) and libgnomeui (bug 352274) have all accepted equivalent patches, so they are happy that AIX and other OS will not be affected.

In cairo they don't expand the macro when it's not gcc or not Solaris.
http://gitweb.freedesktop.org/?p=cairo;a=blobdiff;h=9d1c789d2209aab3f969cc1e6baef5a997826e85;hp=447c1ac0bb8fba938495c26abefaecb3e1f87f78;hb=04757a3aa8deeff3265719ebe01b021638990ec6;f=src/cairoint.h
Comment 7 Brian Cameron 2006-11-22 18:59:41 UTC
I do agree that it would be better if a new macro that doesn't have GCC in its name were created and the current macro made obsolete.  Since so many other modules (Xorg code, cairo, etc.) put the macro at the beginning, I don't see
that it should be a problem to standardize its location there.

Note that currently GCC allows the macro to be placed anywhere in the declaration (before, after, etc), so this doesn't break GCC.  If you review the current GNOME code there is no consistancy about where the macro is placed.  These bugs at least standardize the location to the same location as used in Xorg, at the beginning.  Some consistancy is better than none, I think.

I don't see any problem with accepting this patch.  If another compiler comes along with other requirements, then we can deal with that when the time comes.
Comment 8 Damien Carbery 2007-01-04 15:49:55 UTC
The glib documentation has been changed by Matthais Clasen (bug 373041).
Comment 9 Damien Carbery 2007-05-23 11:52:37 UTC
glib accepted a similar patch recently see bug #438873.
Comment 10 Benoît Dejean 2007-06-26 16:07:39 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.