Re: Upgrading toolchain gcc to 7.2

Hi again,

Unfortunately I was too quick in declaring success. Yes, changing the symbols from <> to "" help but only a bit. It later turned out that the system was doing something ever weirder. When the symbols were changed the gcc/dist/libgcc/configure was looking in the same host include directory as before but the script did not recognize the error right away and the compilation went on. But after some time it stopped again on the same check but for different pre-processor command.

Does anybody have an idea why the script is looking in my host paths? Maybe it's doing it all the time but since You ran it in netbsd the files are the same as the target system (netbsd) so the checks are fine. In other words the error was always there but You just haven't seen it.

As a next step I'll try to build netbsd and run the commands from inside qemu, which is going to take a while but either confirm or disprove my hypothesis.

Cheers,

Radek

2018-01-15 10:09 GMT+01:00 rchmielarz . <radoslaw.chmielarz%gmail.com@localhost>:

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.