Re: include_next with OSF/1 cc

[Bruno Haible]

[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 <address@hidden>:
> > 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