Christer Solskogen via Gcc-help kirjoitti 13.2.2023 klo 9.23: > On 12.02.2023 21:01, Kai Ruottu wrote: >> Christer Solskogen via Gcc-help kirjoitti 12.2.2023 klo 19.51: >>> While cross compiling gcc with musl I see this: >>> >>> checking for exported symbols... >>> /home/solskogen/gcc/libcc1/configure: line 15053: -T: command not found >>> yes >>> checking for -rdynamic... /home/solskogen/gcc/libcc1/configure: line >>> 15063: -T: command not found >>> no >>> checking for library containing dlopen... none required >>> checking for -fPIC -shared... yes >>> configure: error: >>>    Building GCC with plugin support requires a host that supports >>>    -fPIC, -shared, -ldl and -rdynamic. >>> make[1]: *** [Makefile:11890: configure-libcc1] Error 1 >>> >>> This is the configure line: /home/solskogen/gcc/configure >>> --prefix=/usr --libexecdir=/lib --host=aarch64-centrix-linux-musl >>> --target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu >> >> What is intersting in this case is WHICH GCC the build tries to use >> when compiling libgcc. It should be the 'aarch64-centrix-linux-musl' >> targeted cross-GCC, used for the becoming $host >> system to create the executables and libraries for it. So what are >> the CC_FOR_TARGET, GCC_FOR_TARGET, CXX_FOR_TARGET and GXX_FOR_TARGET >> in the main Makefile and in the one >> used for libgcc?  My habit has been years to define these in >> environment before running configure. Maybe these simply don't work >> in the "native Canadian Cross" case. (To create a native >> GCC with a cross-GCC). >> >> > > I see this in configure: > Configuring in ./libcc1 > configure: loading cache ./config.cache > checking build system type... x86_64-pc-linux-gnu > checking host system type... aarch64-centrix-linux-musl > checking target system type... aarch64-centrix-linux-musl > checking for aarch64-centrix-linux-musl-gcc... > aarch64-centrix-linux-musl-gcc > checking whether the C compiler works... yes > > > Which *should* mean that it finds the correct compiler. In the > Makefile I see this: > > CC = aarch64-centrix-linux-musl-gcc > CXX = aarch64-centrix-linux-musl-g++ > GCC_FOR_TARGET=$(STAGE_CC_WRAPPER) aarch64-centrix-linux-musl-gcc > CXX_FOR_TARGET=$(STAGE_CC_WRAPPER) aarch64-centrix-linux-musl-c++ > CC_FOR_TARGET=$(STAGE_CC_WRAPPER) aarch64-centrix-linux-musl-gcc > > All of the other tools also have the aarch64-centrix-linux-musl- > prefix as well, so as far as I understand this *should* work. > For curiousness I tried creating a native gcc for 'x86_64-linux-musl' for which I had target headers and libs from year 2017. I couldn't find equivalent for 'aarch64-linux-musl' in the net, only the libraries in the "Void Linux" pages, but no development headers. I built first a cross-GCC from the gcc-12.2.0 sources with a gcc-5.5.0 as the build/host GCC, then tried to use the new cross-GCC as the host/target compiler. But not defining the GCC_FOR_TARGET, CXX_FOR_TARGET and CC_FOR_TARGET, letting the configure to define them. In my case they of course were wrong because I haven't only one GCC for a target at a time. As told, I had already a toolchain - gcc-7.2.0 based - for 'x86_64-linux-musl' - with exec-suffix '-7.2', so the new one got a suffix '-12'. Ok, making symlinks  with the bare 'x86_64-linux-musl-gcc' etc names to point to the right ones solved this. After this the only problem was trying to also use gcc-12.2.0 as the $build GCC. It was too new and the 'gen*' stuff created for the build $host was linked against the 12.2.0-version of the C++ library but during runtime tried to use the older shared C++ library installed on the host system which didn't work.  So back to using the gcc-5.5.0 for the $build GCC... The native-Canadian Cross succeeded then without any problems. One could only wonder why "reinventing the wheel" would be necessary when the earlier '$host-to-x86_64-linux-musl' cross-compiler already had all the stuff being built for the $target system.  Aren't the separated 'lib/gcc/$target' and 'libexec/gcc/$target' stuff just for this purpose, to make it easy to pack at least the common header and library things? The install command : make DESTDIR=path-to-rootdir install told in : https://gcc.gnu.org/install/finalinstall.html however should enable one to maintain a "temporary staging area or into a |chroot| jail" on the $host system for each 'alien $host'. So maybe "reinventing the wheel" via reproducing the already produced $target stuff has some sanity... I cannot say what the problem with the 'aarch64' architecture could be but what I can see is that your GCC configure options are quite simple when compared to what I "borrowed" from somewhere in 2017 in the 'x86_64' architecture case : [root@AthlonXP2 ~]# x86_64-linux-musl-gcc -v Using built-in specs. COLLECT_GCC=x86_64-linux-musl-gcc COLLECT_LTO_WRAPPER=/opt/cross/bin/../lib/gcc/x86_64-linux-musl/12.2.0/lto-wrapper Target: x86_64-linux-musl Configured with: ../configure --build=i686-linux-gnu --host=i686-linux-gnu --target=x86_64-linux-musl --prefix=/opt/cross --libdir=/opt/cross/lib --libexecdir=/opt/cross/lib --with-sysroot=/opt/host-x86_64-linux-musl --enable-languages=c,c++ --enable-fast-character --disable-libsanitizer --disable-libvtv --disable-libitm --disable-symvers libat_cv_have_ifunc=no --enable-threads=posix --enable-__cxa_atexit --disable-multilib --enable-shared --enable-lto --enable-vtable-verify --enable-linker-build-id --enable-serial-configure --disable-werror --disable-nls --enable-default-pie --enable-default-ssp --enable-checking=release --disable-libstdcxx-pch --with-linker-hash-style=gnu --disable-libunwind-exceptions --disable-target-libiberty --with-default-libstdcxx-abi=gcc4-compatible --with-gxx-include-dir=/opt/cross/include/c++/12.2 --program-prefix=x86_64-linux-musl- --program-suffix=-12 Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.2.0 (GCC)