Arsen Arsenović via Gcc-help kirjoitti 3.8.2023 klo 13.06:
unlvsur unlvsur <unlvsur@xxxxxxxx> writes:
i do set with multilib list, the problem is that gcc gets very messed up when
trying to find where the libs located at build.
like only trying to find lib64 in $targettriple/$targettriple/lib, lib32 in
$targettriple/$targettriple/lib/32, libx32 in
$targettriple/$targettriple/lib/x32
It won't find anywhere else for libc
Please post more information. This could, perhaps, be binutils
misconfiguration.
Sounds sane if one forgot to use the '--with-sysroot=' when configuring
the GNU binutils for
the target system. Here seemingly 'x86_64-linux-androideabi' when
mentioning these three
multilib directories.
It'd be good to see your configuration, gcc -v output, your filesystem
layout, etc.
I checked if I ever had tried building any '*-linux-androideabi'
targeted crosstoolchains. This
happened last in 2015 for the 'arm-linux-androideabi' and with the
latest gcc-4.7, gcc-4.8 and
gcc-4.9 sources being available then. The Android release being "10c" or
something from where
the target C libraries were used. All builds succeeded as expected.
Maybe I could check now the 'x86_64-linux-androideabi' target with the
"Android release 21"
or somehow for which I seem to have the 'lib32', 'libx32' and 'lib64'
subdir stuff for the '/usr' native
install place. Maybe there are newer "NDK"s for Android nowadays.
Telling for which Android
release one aims to build the toolchain is recommended so someone could
use the same target
stuff.
Wondering where on earth the '$targettriple/$targettriple/lib' was
adopted for this job. The
target libraries should be in the "native mirror" places,
'$sysroot/usr/lib*' and the target headers
in the '$sysroot/usr/include', not in the '$prefix/$targettriple/lib*'
and '$prefix/$targettriple/include'
which is the default if one doesn't use the '--with-sysroot='. How the
'$targettriple' became doubled
in the install place?
