On 20 August 2016 at 11:22, ayush goel <ayushgoel1...@gmail.com> wrote: >> >> 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:
Perhaps adding #error is not the best way to test this, since gnulib may still pick the correct headers, but gcc the wrong ones and the error you showed happens when building gnulib. A better way, perhaps, would be to add to unitsdt.h something like #define unitstd_h_gnulib then in some gcc/ file that includes this header, like gcov-tool.c or system.h, you can do just after the #include #ifndef unitstd_h_gnulib #error "unitstd_h_gnulib not defined" #endif Test that it fails when not having the correct INCGNU and that it works when having it. This should settle it, I hope. Cheers, Manuel.
