PETSc never assumes that standards are followed nor that system implementors are intelligent or even sane. Whenever something becomes system dependent (even if the dependence is only because the system developer is insane) PETSc needs a configure test for it. In theory adding new configure tests should be trivial so this is not big deal, in practice ?
Barry On Dec 3, 2010, at 11:59 AM, Satish Balay wrote: > On Fri, 3 Dec 2010, Jed Brown wrote: > >> On Fri, Dec 3, 2010 at 18:27, Satish Balay <balay at mcs.anl.gov> wrote: >> >>> options.c: >>> "/usr/include/sys/feature_tests.h", line 357: #error: "Compiler or options >>> invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99" >>> cc: acomp failed for options.c >>> >> >> Damn, that error is plain wrong. POSIX.1-2001 does include the library >> functions that were added to C99, but it does not say that a C99 compiler >> must be used to access those functions. As I understand the following >> >> _POSIX_C_SOURCE >> Defining this macro causes header files to expose definitions >> as follows: >> >> ? The value 1 exposes definitions conforming to POSIX.1-1990 >> and ISO C (1990). >> >> ? The value 2 or greater additionally exposes definitions for >> POSIX.2-1992. >> >> ? The value 199309L or greater additionally exposes >> definitions for POSIX.1b >> (real-time extensions). >> >> ? The value 199506L or greater additionally exposes >> definitions for POSIX.1c >> (threads). >> >> ? (Since glibc 2.3.3) The value 200112L or greater exposes >> definitions corre? >> sponding to the POSIX.1-2001 base specification >> (excluding the XSI exten? >> sion). >> >> ? (Since glibc 2.10) The value 200809L or greater exposes >> definitions corre? >> sponding to the POSIX.1-2008 base specification >> (excluding the XSI exten? >> sion). >> >> _XOPEN_SOURCE >> Defining this macro causes header files to expose definitions >> as follows: >> >> ? Defining with any value exposes definitions conforming to >> POSIX.1, POSIX.2, >> and XPG4. >> >> ? The value 500 or greater additionally exposes definitions >> for SUSv2 (UNIX >> 98). >> >> ? (Since glibc 2.2) The value 600 or greater additionally >> exposes definitions >> for SUSv3 (UNIX 03; i.e., the POSIX.1-2001 base >> specification plus the XSI >> extension) and C99 definitions. >> >> ? (Since glibc 2.10) The value 700 or greater additionally >> exposes definitions >> for SUSv4 (i.e., the POSIX.1-2008 base specification plus >> the XSI extension). >> >> >> using _POSIX_C_SOURCE=200112L should get the library functions without >> requiring a C99 compiler. My man page for atoll says >> >> atoll(): >> _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 600 || >> _ISOC99_SOURCE || >> _POSIX_C_SOURCE >= 200112L; >> or cc -std=c99 >> >> >>> Looks lie I have to remove both _BSD_SOURCE and _POSIX_C_SOURCE to get >>> the compile going. >>> >> >> This is just crazy. >> >> >>>> If this doesn't work, how does one guarantee that atoll is >>>> available on Solaris? >>> >>> I guess its always available. The examples work [after removing both >>> the above lines]. The man page lists the following: >>> >> >> Note that "gcc -std=c89 -Wall" warns about atoll not being available (gcc >> defines _GNU_SOURCE by default, which I guess could have been added to the >> list above except that GNU is not a recognized standards-issuing authority). >> I would be surprised if all other platforms have it by default. I guess >> our options are >> >> 1. have a configure test and wrap those macros appropriately > > We always have problems understanding and following standards - and > rely on configure tests [and using watever works..]. Perhaps there > should be a configure test for atoll() with and without the above > macros.. > > Satish > >> 2. shoot from the hip, remove the test and hope no other compiler is strict >> 3. have OpenSolaris users just build with a C99 compiler >> >> Jed >>
