Problem cross-compiling gcc

[Kai Ruottu]

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)