From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fgw22-4.mail.saunalahti.fi (fgw22-4.mail.saunalahti.fi [62.142.5.109]) by sourceware.org (Postfix) with ESMTPS id 5318B3858D33 for ; Mon, 13 Feb 2023 10:30:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5318B3858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=wippies.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=wippies.com Received: from [10.0.0.82] (mobile-access-2e8429-181.dhcp.inet.fi [46.132.41.181]) by fgw22.mail.saunalahti.fi (Halon) with ESMTPSA id 746c9cfb-ab89-11ed-9ddd-005056bdf889; Mon, 13 Feb 2023 12:30:37 +0200 (EET) Content-Type: multipart/alternative; boundary="------------N5jYDGCuZWWRBNo5309Bza9s" Message-ID: <39455f9f-de9a-cded-43b2-f31cdd676541@wippies.com> Date: Mon, 13 Feb 2023 12:30:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: Problem cross-compiling gcc To: Christer Solskogen , gcc-help@gcc.gnu.org References: From: Kai Ruottu In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------N5jYDGCuZWWRBNo5309Bza9s Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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) --------------N5jYDGCuZWWRBNo5309Bza9s--