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.