>
> We're talking about a one-line change, but this is absolutely
> crucial and central to use of gnulib. Until this is correct,
> any previous host-specific testing is invalid, unfortunately.
>
> In the previous revision, you had:
>
> INCGNU = -I../gnulib -I$(srcdir)/../gnulib/import
>
> and I was expecting to see in the new revision something
> like:
>
> INCGNU = -I../gnulib/import -I$(srcdir)/../gnulib/import
>
> or perhaps even better:
>
> INCGNU = -I$(build_libobjdir)/gnulib/import -I$(srcdir)/../gnulib/import
>
> Try hacking one of the generated replacement headers, one that gcc
> is sure to include, to cause a compilation error. E.g. add an #error call
> to the generated gnulib/import/unistd.h. If a gcc build, from scratch since
> there are no Makefile dependencies, still compiles with that, then we're
> still not picking the right headers.
So your concern seems valid, however the build process seems to pick
the correct headers.
I did try to raise an error from the gnulib generated header unitstd.h
and it gives me a compile time error:
--------------------------------------------------------------
gcc -DHAVE_CONFIG_H -I. -I/Users/ayushgoel/gsoc/src/gnulib/import -I..
-g -O2 -MT exitfail.o -MD -MP -MF .deps/exitfail.Tpo -c -o
exitfail.o /Users/ayushgoel/gsoc/src/gnulib/import/exitfail.c
gcc -DHAVE_CONFIG_H -I. -I/Users/ayushgoel/gsoc/src/gnulib/import -I..
-g -O2 -MT unistd.o -MD -MP -MF .deps/unistd.Tpo -c -o unistd.o
/Users/ayushgoel/gsoc/src/gnulib/import/unistd.c
gcc -DHAVE_CONFIG_H -I. -I/Users/ayushgoel/gsoc/src/gnulib/import -I..
-g -O2 -MT obstack.o -MD -MP -MF .deps/obstack.Tpo -c -o obstack.o
/Users/ayushgoel/gsoc/src/gnulib/import/obstack.c
In file included from /Users/ayushgoel/gsoc/src/gnulib/import/unistd.c:3:
./unistd.h:18:2: error: “Unistd header file being invoked"
#error “unistd from gnulib being invoked"
^
config.status: creating config.h
1 error generated.
make[5]: *** [unistd.o] Error 1
Also, I’m sure of the fact that gnulib headers are being used because
all the functions that I’ve replaced from libiberty, I locally removed
both the .c and .h files from libiberty to confirm that the gnulib’s
version is indeed being used, and it compiled just fine.
I’m not really sure how else it is being able to figure out where to
look for the header files however just to be on the safer side I’ve
made the change that you’ve mentioned.
>
> > Index: src/gcc/mkconfig.sh
> > ===================================================================
> > --- src/gcc/mkconfig.sh (revision 237184)
> > +++ src/gcc/mkconfig.sh (working copy)
> > @@ -43,6 +43,7 @@
> > # A special test to ensure that build-time files don't blindly use
> > # config.h.
> > if test x"$output" = x"config.h"; then
> > + echo '#include "../gnulib/config.h"' >> ${output}T
> > echo "#ifdef GENERATOR_FILE" >> ${output}T
> > echo "#error config.h is for the host, not build, machine." >> ${output}T
> > echo "#endif" >> ${output}T
>
> Hmm, this looks incorrect/incomplete, for not considering the generator
> programs that are built for the "build" machine. AFAICS, those include
> "bconfig.h" instead of "config.h". Note the GENERATOR_FILE check above.
>
> My recollection is that those build-machine programs link with libiberty
> too today, and should thus switch to gnulib as well, right?
>
So my understanding of this is that the gnulib.h is also required to
be included inside bconfig.h?
