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)
