Re: gnulib breakage on Tru64 UNIX with commercial C compiler

[Albert Chin]

On Wed, Apr 04, 2007 at 09:14:12PM -0600, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Albert Chin on 4/4/2007 8:59 PM:
> > 
> > Unfortunately, "#include_next <stdio.h>" doesn't include
> > /usr/include/stdio.h. It includes "./stdio.h", the gnulib version of
> > stdio.h.
> 
> If you were to change the gnulib stdio.h to use #include_next instead of
> #include, would that help matters any?  Maybe we need to teach the
> absolute-header module to check for include_next, and use it when
> supported?  Although I seem to recall the concern over this was whether
> preprocessors that don't understand #include_next would choke; so it would
> have to be done by one of the sed expressions that creates stdio.h from
> stdio_.h rather than something directly in stdio_.h.

If I change:
  #include "///usr/include.dtk/stdio.h"
to:
  #include_next <stdio.h>
then it works as expected (./stdio.h, /usr/include.dtk/stdio.h,
/usr/include/stdio.h).

If I #include_next "///usr/include.dtk/stdio.h", it does not.

> > So, how do we fix this? There is a -nodtk option to the commercial C
> > compiler which reverts to the system cc but that would need to be done
> > for _most_ gnulib-using programs, something that is not desirable.
> 
> Doable in gnulib (similar to how we turn on c99 mode on as many compilers
> as possible), but still awkward.  Also, is there a different sequence of
> - -I flags that would pick up the system headers correctly?

None I know of. Adding -I/usr/include after -I. doesn't help.

-- 
albert chin (address@hidden)