tech-toolchain archive

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

Re: Upgrading toolchain gcc to 7.2



It turned out to be a bug (or a feature depending on how do You count) of gcc configure script. In src/external/gpl3/gcc/dist/gcc/configure:5425 it says:

"  # Use a header file that comes with gcc, so configuring glibc
  # with a fresh cross-compiler works.
  # Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
  # <limits.h> exists even on freestanding compilers.
  # On the NeXT, cc -E runs the code through the compiler's parser,
  # not just through cpp. "Syntax error" is here to catch this case.
  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h.  */
#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif
             Syntax error
_ACEOF"

And this was the test that was checking if C preprocessor is working. But neither limits.h nor assert.h were is the system includes as we have no includes in tooldir at this point. But the intention of this test was to look for the header files provided with gcc itself and not the system. Hence following CPP reference (http://en.cppreference.com/w/cpp/preprocessor/include) when I have changed the snippet to use # include "limits.h" and # include "assert.h" it worked as it first looked in current dir and only then in system wide includes.

I will ask in gcc mailing list about this, but this has fixed this particular issue with mknative for me.

Cheers,
Radek

2018-01-12 7:56 GMT+01:00 rchmielarz . <radoslaw.chmielarz%gmail.com@localhost>:
Hmm, Ok, I'll look into that, but like I'm saying - exactly the same thing is happening for me in netbsd current. Same kind of errors. I'm building it on linux.

2018-01-11 23:25 GMT+01:00 matthew green <mrg%eterna.com.au@localhost>:
> taking are correct, but the config.log for minix says:
>
> configure:3811: result: unsupported
> configure:3833: checking how to run the C preprocessor
> configure:3864:
> /home/radzio/experiments/obj.evbearm-el/tools/gcc/build/./gcc/xgcc
> -B/home/radzio/experiments/obj.evbearm-el/tools/gcc/build/./gcc/
> -B/home/radzio/experiments/minix/../obj.evbearm-el/tooldir.Linux-4.14.5-1-ARCH-x86_64/arm-elf32-minix/bin/
> -B/home/radzio/experiments/minix/../obj.evbearm-el/tooldir.Linux-4.14.5-1-ARCH-x86_64/arm-elf32-minix/lib/
> -isystem
> /home/radzio/experiments/minix/../obj.evbearm-el/tooldir.Linux-4.14.5-1-ARCH-x86_64/arm-elf32-minix/include
> -isystem
> /home/radzio/experiments/minix/../obj.evbearm-el/tooldir.Linux-4.14.5-1-ARCH-x86_64/arm-elf32-minix/sys-include
> -E  conftest.c
> In file included from conftest.c:10:0:
> /usr/include/limits.h:124:26: error: no include path in which to search for
> limits.h
>  # include_next <limits.h>

hmmm -- this is trying to include the *host* <limits.h> which is
definately wrong.  sounds like something in the GCC configury for
minix is always adding /usr/include to the include path.  that's
a big problem for a cross compiler.

i'd guess you should fix this and see what happens next.


.mrg.




Home | Main Index | Thread Index | Old Index