GNOME Bugzilla – Bug 339924
pygobject doesn't compile on opensolaris
Last modified: 2007-08-27 12:47:59 UTC
gnome-python (pygobject, pycairo, pyorbit) doesn't compile on opensolaris. It fails with the following #error: http://jhbuild.bxlug.be/builds/2006-04-27-0002/logs/gnome-python%5Cpygobject/#build /usr/include/sys/feature_tests.h:353:2: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" The relevant part of /usr/include/feature_tests.h is: /* * 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 so I think you need to #define _XPG6 for it to work.
Seems like OpenSolaris does not like -std=c9x
This looks similar to bug 335240.
*** Bug 437205 has been marked as a duplicate of this bug. ***
The Sun Studio compiler (used on OpenSolaris) doesn't like -Wall or -fno-strict-aliasing. The patch at Bug 437205 should be an easy solution.
(In reply to comment #4) > The Sun Studio compiler (used on OpenSolaris) doesn't like -Wall or > -fno-strict-aliasing. Are you sure itsn't not only c9x that's causing the problem? > The patch at Bug 437205 should be an easy solution. I committed something else, based on comments in http://wiki.netbsd.se/index.php/Typical_pkgsrc_error_messages.
$ cat me.c #include <stdio.h> int main(void) { printf("Hello\n"); } $ cc -V cc: Sun C 5.8 Patch 121016-05 2007/01/10 usage: cc [ options] files. Use 'cc -flags' for details $ cc -Wall me.c cc: illegal option -Wall $ cc -fno-strict-aliasing me.c cc: Warning: illegal option -fno-strict-aliasing $ cc -std=c9x me.c cc: Warning: illegal option -d=c9x
(In reply to comment #6) > $ cat me.c > #include <stdio.h> > > int main(void) > { > printf("Hello\n"); > } > > $ cc -V > cc: Sun C 5.8 Patch 121016-05 2007/01/10 > usage: cc [ options] files. Use 'cc -flags' for details > $ cc -Wall me.c > cc: illegal option -Wall > $ cc -fno-strict-aliasing me.c > cc: Warning: illegal option -fno-strict-aliasing > $ cc -std=c9x me.c > cc: Warning: illegal option -d=c9x What is the exit code ($?) of the compiler in each case?
$ cc -V; echo $? cc: Sun C 5.8 Patch 121016-05 2007/01/10 usage: cc [ options] files. Use 'cc -flags' for details 1 $ cc -Wall me.c; echo $? cc: illegal option -Wall 1 $ cc -fno-strict-aliasing me.c; echo $? cc: Warning: illegal option -fno-strict-aliasing 0 $ cc -std=c9x me.c; echo $? cc: Warning: illegal option -d=c9x 0 $ cc me.c; echo $? 0
configure.ac has several invocations of the JH_ADD_CFLAG macro, which tries to compile something and see if an error is produced. Apparently only -Wall is really an error; the rest are just warnings. It Should Work™. But -std=c9x is worrying: from the error message it seems that the compiler accepts -s and -t, and god knows what side effects these switches cause. :| It's probably safer to just apply your patch.
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.
This doesn't work for me on Solaris 10 using GCC. Python 2.5.1's pyconfig.h defines _XOPEN_SOURCE=500, which overrides pygobject's command-line option, -D_XOPEN_SOURCE=600. This leads to the feature_tests.h error originally reported by James Andrewartha. According to Solaris 10's standards(5) man page, defining _XOPEN_SOURCE=500 requests SUSv2 and requires the use of a C89 compiler, whereas defining _XOPEN_SOURCE=600 requests SUSv3 and requires using a C99 compiler. feature_tests.h enforces this. I was able to fix my build by removing -std=c9x from configure.ac and removing -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ from gobject/Makefile.am and tests/Makefile.am. If you don't need C99 or the SUSv3 features (whatever they are), then maybe this will work for everyone (?).
Created attachment 94236 [details] [review] Remove -std=c9x and -D_XOPEN_SOURCE=600 -D__EXTENSIONS__
Removed-D_XOPEN_SOURCE=600 and -D__EXTENSIONS__, conditionally removed -std=c9x only on solaris. Should be fixed for real now.