Unable to build libgcc for target x86_64-w64-mingw32, C preprocessor /lib/cpp fails sanity check

[Kai Ruottu]

Christer Solskogen kirjoitti 23.9.2018 klo 0.56:
> On 9/22/2018 10:23 PM, Juan Pablo Garibotti Arias wrote:
>> I'm trying to build a cross compiler for UEFI, and having difficulties
>> building libgcc after having built the compilers themselves. I've 
>> already
>> built a cross compiler and libgcc (with and without red-zone) for
>> freestanding x86_64-elf in the same machine, so not sure what the 
>> issue is.
>> The source for gcc was downloaded to ~/src/gcc. After that, I did:
>> export PREFIX="$HOME/opt/cross"
>> export TARGET=x86_64-w64-mingw32
>> export PATH="$PREFIX/bin:$PATH"
>> mkdir ~/src/gcc-build-$TARGET
>> cd ~/src/gcc-build-$TARGET
>> ../gcc/configure --target=$TARGET --prefix="$PREFIX" --disable-nls
>> --enable-languages=c,c++ --without-headers
> The build order I use is something like this:
> binutils
> gcc (all-gcc && install-gcc)
> mingw-headers
> mingw-crt
> full gcc

With an already existing target which has an already built and tested 
target C libraries
like 'x86_64-w64-mingw32' and 'x86_64-redhat-linux' (CentOS, Fedora) it 
is quite vain
and even questionable (will the result really be the same?) to try to 
rebuild this already
existing target C library stuff.  One could ask oneself whether one 
really would rebuild
the target C library stuff in the native GCC case.  If not, why on earth 
in the cross GCC
case?  (A resurrection of the native GCC for the target on another host 
with only new
executables for the new cross host)

So just choosing a SYSROOT to keep the already existing target stuff (in 
this case as
downloaded mingw-packages from the MinGW site) and using the 
'--with-sysroot=$SYSROOT'
to point to them when configuring GNU binutils and GCC, would be the 
recommendation
from me. If one chooses PREFIX="$HOME/opt/cross" (for keeping all the 
crosstools) then
a quite obvious choose for the TARGET stuff would be to use 
SYSROOT=$PREFIX/host-$TARGET,
in this case it would lead using 
'$HOME/opt/cross/host-x86_64-w64-mingw32' as the SYSROOT
for the MinGW stuff.  When making more  crosstoolchains one then uses 
the same standard,
for instance with a crosstoolchain for 'x86_64-centos7-linux' one would 
use the
'$HOME/opt/cross/host-x86_64-centos7-linux' as the SYSROOT for the 
CentOS7 stuff and
the '$HOME/opt/cross/bin' for the 'x86_64-centos7-linux-*' named 
executables.

With the "embedded targets" like 'x86_64-elf' one doesn't use any 
SYSROOT because there
aren't any "existing target standard C libraries" but one usually 
compiles them from the newlib
sources at the same time with the GCC sources.  The resulting standard C 
libraries will go into
the default '$PREFIX/$TARGET/include' and '$PREFIX/$TARGET/lib', in the 
previous "standard"
into the '$HOME/opt/cross/x86_64-elf/include' and 
'$HOME/opt/cross/x86_64-elf/lib' in the
'x86_64-elf' target case.  Whether newlib now supports the 'x86_64-elf' 
target I have no clue,
the 'i386-elf' has been there from the very beginning and I remember 
toying with it to make
a crosscompiler which could make simple executables for both DJGPP2 on 
MS-DOS and Unix
SVR4.2 (UnixWare and Linux with ibcs2).