Yaxuan Wen via Gcc-help kirjoitti 18.1.2024 klo 1.23:
> Dear developer,
>
> Hope this email finds you well. I'm trying to compile a native gcc (called
> it turtle-gcc for communication) from source using a cross-compiler gcc.
>
> Here is the configuration file I used:
>
> export CFLAGS="-ffloat-store"
> export CXXFLAGS="-ffloat-store"
>
> ../gcc-4.4.3/configure --enable-languages=c --disable-shared \
> <clip>
>    --build=x86_64-linux --host=x86_64-nacl-linux --target=x86_64-nacl-linux
>
> I have no idea what causes this error, could you please provide some
> instructions? Many thanks!

The prerequisites in your case are aworking compiler for 
the'x86_64-linux' build system and a working cross-compiler from the 
build/host 'x86_64-linux' system to the target 'x86_64-nacl-linux' 
system. Whether the GCC configure scripts could quess what tools the 
build should use for the $host and $target I have no clue. Years I have 
always defined these with the : AR=<something> \ CC= <something> \ 
CXX=<something> \ .... RANLIB=<something> \ for the $host system. And : 
AR_FOR_TARGET=<something> \ CC_FOR_TARGET= <something> \ 
CXX_FOR_TARGET=<something> \ .... RANLIB_FOR_TARGET=<something> \ for 
the $target system. Similarly for the $build system with the : 
<TOOL>_FOR_BUILD=<something> rows in the script used as the
configure command, before the final 'configure' command in it.
Not much left to guess...

The already existing cross-compiler for the $target should be
used to compile all the usual target libraries like 'libgcc' during
the build. But they already were built during the cross-compiler
build so producing them once again is basically "reinventing the
wheel". So using the command :

make all-gcc

would be enough in order to get the executables for the new
native compiler, 'xgcc', 'cc1', 'collect2' etc.

The errors you got are the result of the just built GCC being
used to compile 'libgcc'. It of course searches its headers and
libraries from the "native places" which in your case are those
for the $build system. Seemingly its executables can somehow
work on your $build system. If the CPU arch would be different
the erors would come about the new 'xgcc' not working on the
$build system.

Furthermore using the '--prefix=/usr' for a native GCC aimed
as the 1st GCC there or as a replacement for the existing GCC
on the target system is usual. Without any '--prefix=<something>'
the '/usr/local' will be used as the default install prefix.