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 ([EMAIL PROTECTED])
