On 08/10/2016 05:31 PM, ayush goel wrote:
> On 10 August 2016 at 7:36:41 PM, Pedro Alves (pal...@redhat.com) wrote:
> So I was getting the exact same error as above and that is precisely
> why I included "-I../gnulib” in the include path. I figured the
> compiler wasn’t able to find config.h and hence has to be pointed to
> the right path.
>
> Excuse my limited understanding of the system, but the compiler seems
> to already require config.h while building, and therefore doesn’t
> having “-I../gnulib” solve the problem?
> Why should I remove this from the path and instead have “#include
> config.h” inside every function of gcc using gnulib.
> Any explanation would be sincerely appreciated.
Puzzling how that didn't cause other problems for you.
Because:
- we end up with two different config.h files:
build/gcc/config.h
build/gnulib/config.h
- #include "config.h"' will pick one or the other, but not both.
- we need to include both.
Now, now that I look at gcc's config.h, it doesn't look like that
is the standard config.h file autogenerated from config.in at all.
Ah. It's a custom file. The one generated from gcc/config.in is
build/gcc/auto-host.h. From configure.ac:
# auto-host.h is the file containing items generated by autoconf and is
# the first file included by config.h.
# If host=build, it is correct to have bconfig include auto-host.h
# as well. If host!=build, we are in error and need to do more
# work to find out the build config parameters.
if test x$host = x$build
then
build_auto=auto-host.h
else
So it sounds like you could include gnulib's config.h from within
gcc's config.h directly. Looks like that file is generated
by src/gcc/mkconfig.sh, so that's what you'd patch.
Thanks,
Pedro Alves
