bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib breakage on Tru64 UNIX with commercial C compiler


From: Albert Chin
Subject: Re: gnulib breakage on Tru64 UNIX with commercial C compiler
Date: Fri, 6 Apr 2007 11:16:51 -0500
User-agent: Mutt/1.5.6i

On Wed, Apr 04, 2007 at 10:45:44PM -0500, Albert Chin wrote:
> 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.

I'll work on a patch for #include_next support.

-- 
albert chin (address@hidden)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]