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 762562 - error: #pragma GCC diagnostic not allowed inside functions
error: #pragma GCC diagnostic not allowed inside functions
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
2.47.x
Other Mac OS
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2016-02-23 20:09 UTC by Ryan Schmidt
Modified: 2016-03-22 04:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ryan Schmidt 2016-02-23 20:09:28 UTC
Building glib 2.47.6 fails with Apple GCC 4.2.1 with the following errors:

gdate.c: In function 'g_date_strftime':
gdate.c:2497: error: #pragma GCC diagnostic not allowed inside functions
gdate.c:2498: error: #pragma GCC diagnostic not allowed inside functions
gdate.c:2500: error: #pragma GCC diagnostic not allowed inside functions
make[4]: *** [libglib_2_0_la-gdate.lo] Error 1

Here is a full build log:

https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/40612/steps/compile/logs/stdio

Here is the code from gdate.c causing this error:

      #pragma GCC diagnostic push
      #pragma GCC diagnostic ignored "-Wformat-nonliteral"
      tmplen = strftime (tmpbuf, tmpbufsize, locale_format, &tm);
      #pragma GCC diagnostic pop

The LLVM guys say "non-literal strftime format string is not unsafe" so there should be no need for these pragmas:

http://llvm.org/viewvc/llvm-project?view=revision&revision=150009

though I guess you added them because some version of GCC complains otherwise. Removing them allows glib 2.47.6 to build with GCC 4.2.1.

Yes, this build failure is observed on OS X 10.6, and I know glib's configure script bails out on OS X < 10.9; yes, I have removed that configure check and the use of the gcocoanotification backend from glib in MacPorts when on OS X < 10.9 because I am not ready to cut off support from users of OS X < 10.9.
Comment 1 Matthias Clasen 2016-02-23 20:12:12 UTC
whats this bug asking for ? do you expect us to make changes to support an old compiler on an OS that we refuse to even configure on ?
Comment 2 Ryan Schmidt 2016-02-23 20:16:05 UTC
I'm asking for you to continue to support compiling with GCC versions less than 4.4. https://wiki.gnome.org/Projects/GLib/CompilerRequirements does not mention that versions of GCC older than 4.4 don't work, so I hoped it was an oversight that could be corrected. I believe the fact that for me this happened on an unsupported version of OS X is incidental; I assume this same problem would happen when using GCC < 4.4 on another OS.
Comment 3 Matthias Clasen 2016-02-23 20:32:46 UTC
Both GLib and GTK+ are commonly using G_GNUC_BEGIN/END_IGNORE_DEPRECATIONS inside functions, and that is just the same, modulo #pragma vs _Pragma. Is your gcc not warning about that ?
Comment 4 Ryan Schmidt 2016-02-23 20:35:46 UTC
If I remove the three #pragmas from g_date_strftime in gdate.c, the build succeeds. Here is the log:

https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/40614/steps/compile/logs/stdio
Comment 5 Ryan Schmidt 2016-03-22 04:02:00 UTC
This was fixed in 8cdbc7fb2c8c876902e457abe46ee18a0b134486 which was included in glib 2.47.92.