[Re-adding bug-gnulib in CC. This is a reply to a reply to <http://lists.gnu.org/archive/html/bug-gnulib/2009-01/msg00313.html>.]
Hi Gary, Gary V. Vaughan wrote: > 2009/1/24 Bruno Haible <br...@clisp.org>: > > Gary V. Vaughan wrote: > >> !THE FOLLOWING IS A REGRESSION OVER m4-1.4.12, WHICH COMPILES AND > >> PASSES ALL TESTS! > >> alphaev5-dec-osf4.0d-cc55 fails to compile: > >> cc -std -I. -ieee -O2 -nodtk -msym -readonly_strings -c -o > >> gl_avltree_oset.o gl_avltree_oset.c > >> cc: Warning: ///usr/include.dtk/stdlib.h, line 26: "include_next" is > >> an invalid preprocessor directive, and is being ignored. > >> #include_next <stdlib.h> > >> -^ > >> cc: Warning: ///usr/include.dtk/stdio.h, line 27: "include_next" is an > >> invalid preprocessor directive, and is being ignored. > >> #include_next <stdio.h> > >> -^ > > > > It looks like you set CC="cc -std" and > > CFLAGS="-ieee -O2 -nodtk -msym -readonly_strings". Apparently gnulib > > avoids include_next, but the configure tests found out that the location > > of the system's <stdlib.h> file is ///usr/include.dtk/stdlib.h. But > > when the -nodtk option is in use, this file should not even be seen. > > > > I'd suggest that you use CC="cc -std -nodtk" and > > CFLAGS="-ieee -O2 -msym -readonly_strings". > > I'm not sure how the `-nodtk' crept in... maybe from a build recipe we > were using on a previous release. > > Anyway, rebuilding that same snapshot with the same settings I use for > a successful build of m4-1.4.12 (the -ieee option is added later by > gl_FP_IEEE), I now see the following: > > $ ./configure CC=cc CFLAGS="-O2 -msym -readonly_strings" > ... > checking for inttypes.h... yes > ... > checking for libsigsegv... no, consider installing GNU libsigsegv > checking whether system is Windows or MSDOS... no > checking whether // is distinct from /... no > checking whether the preprocessor supports include_next... yes > ... > Checking ./stackovf.test > Stack soft limit set to 8192K > Pass > > Skipped checks were: > ./122.changeword ./123.changeword ./124.changeword ./125.changeword > ./126.changeword ./127.changeword > All checks successful > ... > gmake[5]: Entering directory `/opt/build/m4-1.4.12.16-307f/tests' > ... > cc -I. -I../lib -I. -I. -I.. -I./.. -I../lib -I./../lib -ieee -O2 > -msym -readonly_strings -c test-wctype.c > cc: Severe: /usr/include.dtk/inttypes.h, line 319: Cannot find file > <inttypes.h> specified in #include directive. (noinclfilef) > #include_next <inttypes.h> > -^ > gmake[5]: *** [test-wctype.o] Error 1 > gmake[5]: Leaving directory `/opt/build/m4-1.4.12.16-307f/tests' > ... > > Which is pretty odd, considering: > > $ find /usr/include -name inttypes.h > $ find /usr/include.dtk -name inttypes.h > /usr/include.dtk/inttypes.h > > Our other osf5 machine also has /usr/include/inttypes.h, so either we > have a bad installation of osf4, or maybe DEC messed up at this patch > level. Either way, I'm surprised I haven't tripped this particular > issue before (and I have built literally *thousands* of configure based > packages on this machine)... Yes, I too consider it a broken installation if the DTK <inttypes.h> wants to include a non-DTK <inttypes.h> file that does not exist. > So, trying again with your suggested settings: > > $ ./configure CC="cc -nodtk" and CFLAGS="-O2 -msym -readonly_strings" > ... > checking for cc -nodtk option to accept ISO C89... -std > ... > checking for cc -nodtk -std option to accept ISO C99... unsupported > checking for cc -nodtk -std option to accept ISO C89... (cached) -std > checking for cc -nodtk -std -std option to accept ISO Standard C... > (cached) -std > ... > checking for libsigsegv... no, consider installing GNU libsigsegv > checking whether system is Windows or MSDOS... no > checking whether // is distinct from /... no > checking whether the preprocessor supports include_next... no > ... > checking for inttypes.h... no > ... > cc -nodtk -std -std -I. -I../lib -I. -I. -I.. -I./.. -I../lib > -I./../lib -ieee -O2 -msym -readonly_strings -c test-wctype.c > cc -nodtk -std -std -O2 -msym -readonly_strings -o test-wctype > test-wctype.o libtests.a ../lib/libm4.a libtests.a -lm > ... > ====================== > All 60 tests passed > (8 tests were not run) > ====================== > > But now, everything is compiled with 'cc -nodtk -std -std -ieee...', > and -nodtk seems to turn off #include_next support, neither of which > seems exactly right. The result is perfect. Who cares whether the gnulib uses include_next or not, if the package compiles fine? > However, it turns out that I can get a cleaner looking build that > passes tests by helping gnulib discover that inttypes.h does not > compile: > > $ ./configure CC=cc CFLAGS="-O2 -msym -readonly_strings" \ > ac_cv_header_inttypes_h=no > ... > checking whether the preprocessor supports include_next... yes > ... > checking for inttypes.h... no > ... > cc -I. -I../lib -I. -I. -I.. -I./.. -I../lib -I./../lib -ieee -O2 > -msym -readonly_strings -c test-wchar.c > cc -O2 -msym -readonly_strings -o test-wchar test-wchar.o > libtests.a ../lib/libm4.a libtests.a -lm > ... > ====================== > All 60 tests passed > (8 tests were not run) > ====================== > > Still seems like a regression over 1.4.12 to me :-b It's not a regression because you are supposed to use the -nodtk option if you encounter problems with the DTK compiler and its header files. It's documented in the INSTALL file (see gnulib/doc/INSTALL*). I had written this paragraph because of a broken DTK <wchar.h>. The include file that is now broken is DTK <inttypes.h>. Bruno
