GNOME Bugzilla – Bug 133344
_POSIX_SOURCE causes compile problem in glib
Last modified: 2011-02-18 16:14:20 UTC
On Solaris, trying to compile glib/giounix.c fails with the following error: "/usr/include/sys/feature_tests.h", line 263: #error: "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" This problem goes away if the following line is removed. #define _POSIX_SOURCE /* for SSIZE_MAX */ This define doesn't seem to be needed in the giounix.c file, and the file compiles fine on Solaris without it. Can this be removed, or only included on platforms that it is needed? Thanks!
That was introduced to fix bug 128853. I suppose I could use _GNU_SOURCE, but I'd hoped to address the issue on non-glibc platforms too. That error doesn't make much sense to me (and is not in the headers on the Solaris 9 box I just looked at). Are you using gcc? what happens if you compile with -ansi?
I am using the Forte compiler on Solaris. I am using a development version of SolarisNext (the one that will be released after Solaris 9). So that is why the headers are different than what you see. Forte supports these options: -Xa Compile assuming ANSI C conformance, allow K & R extensions (default mode) -Xc Compile assuming strict ANSI C conformance -Xs Compile assuming (pre-ANSI) K & R C style code -Xt Compile assuming K & R conformance, allow ANSI C I believe -Xa is the equilivant of -ansi for the gcc compiler. I tried using all of the above 4 options, and they all fail to compile. If you want to #ifdef the logic so that it doesn't get used on Solaris, you could surround the #define with the following #ifndef __SUNPRO_C #endif __SUNPRO_C is defined if you are compiling with Forte.
I'd rather try to figure out the right thing rather than do compiler specific #ifdefs, especially since I don't know what will happen with gcc. In limits.h (or wherever it is defined), what is the definition of SSIZE_MAX guarded by? Also, what is that #error guarded by?
The error is guarded by (from /usr/include/sys/feature_tests.h): /* * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 * or a POSIX.1-2001 application with anything other than a c99 or later * compiler. Therefore, we force an error in both cases. */ #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ and pre-2001 POSIX applications" #elif !defined(_STDC_C99) && \ (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications \ require the use of c99" #endif ---- SSIZE_MAX is guarded by: #if defined(__EXTENSIONS__) || !defined(_STRICT_STDC) || \ defined(__XOPEN_OR_POSIX) #define SSIZE_MAX LONG_MAX /* max value of an "ssize_t" */ [..] #endif /* defined(__EXTENSIONS__) || !defined(_STRICT_STDC) ... */ ---
Hmm, it looks like with Solaris 9 headers and gcc -ansi, #define _POSIX_SOURCE is needed as well, so papering it over with _GNU_SOURCE instead won't work. Probably the same thing will happen on Solaris 10 once gcc's fixincludes is changed to recognize _STRICT_STDC. I'm really not sure what to do here. What do the Sun docs recommend for an app that is both POSIX-1.1990 and POSIX.1-2001 compliant?
It looks like we somehow need to get _XPG6 defined...
Brian, any progress on this front ? Is this still a problem ? Should we just close this bug ?
Yes, we work around this problem with Forte by adding a patch that says this just before the #include "config.h" in giounix.c +#ifdef _STDC_C99 +#undef _STDC_C99 +#endif
Created attachment 135013 [details] [review] Patch fixing the problem Defining _XOPEN_SOURCE to 600 fixes the compilation problem.
I wonder if it is not redundant to define both _POSIX_SOURCE and _XOPEN_SOURCE.
Doing some research on the patches that Sun applies, I see that we are not applying this patch anymore. The patch was removed after glib was bumped to 2.12.4 in December 2006. So I believe this issue was resolved via some other way. I think this bug can just be closed.
thanks for the update