On 14.02.25 10:52, Helmut Grohne wrote:
Control: retitle -1 gcc-VER-TRIPLET may use binutils for a different
architecture
Control: severity -1 important
Control: tags -1 = confirmed patch
On Thu, Oct 03, 2024 at 12:40:53PM +0200, Erez wrote:
Just update my trixie container.
builder@5ba2a4b665d9:~$ cat /etc/debian_version
trixie/sid
builder@5ba2a4b665d9:~$ dpkg --print-architecture
amd64
builder@5ba2a4b665d9:~$ dpkg --print-foreign-architectures
arm64
Using the cross compiler to arm64:
ii binutils-aarch64-linux-gnu:arm64 2.43.1-5
arm64 GNU binary utilities, for aarch64-linux-gnu target
ii cpp-14-aarch64-linux-gnu:arm64 14.2.0-3
arm64 GNU C preprocessor for aarch64-linux-gnu
ii cpp-aarch64-linux-gnu 4:14.1.0-2
amd64 GNU C preprocessor (cpp) for the arm64 architecture
ii g++-14-aarch64-linux-gnu:arm64 14.2.0-3
arm64 GNU C++ compiler for aarch64-linux-gnu architecture
ii g++-aarch64-linux-gnu 4:14.1.0-2
amd64 GNU C++ compiler for the arm64 architecture
ii gcc-14-aarch64-linux-gnu:arm64 14.2.0-3
arm64 GNU C compiler for the aarch64-linux-gnu architecture
ii gcc-aarch64-linux-gnu 4:14.1.0-2
amd64 GNU C compiler for the arm64 architecture
And run:
builder@5ba2a4b665d9:~$ printf 'void main(){}' | aarch64-linux-gnu-gcc -xc -
as: unrecognized option '-EL'
Thank you. I could easily reproduce the issue given this information.
Before I go into the details of the problem, let me note that your setup
is fairly unusual. Your native/build architecture is amd64. You intend
to compile for arm64. In that case, most people would install
gcc-14-aarch64-linux-gnu:amd64, but you opted for
gcc-14-aarch64-linux-gnu:arm64. Please assist with figuring out why this
happened. For instance, you might try installing
gcc-14-aarch64-linux-gnu:amd64 and see what apt would want to remove
then.
Quite definitely, I caused this problem in the -for-host transition.
Beofre it, the native gcc was bundled in gcc-14 and
gcc-14-aarch64-linux-gnu:arm64 simply would not exist. I split out this
package and in doing so, I enabled this problem. It does not happen for
cross toolchains, because there we pass --with-as=... and --with-ld=...
pointing gcc at triplet-prefixed binutils. In the native case, we do not
pass --with-as nor --with-ld. As a result, gcc simply executes "as" and
"ld". In your case, this very likely comes from binutils:amd64 and the
architecture does not match at all. I partially saw this problem, which
is why binutils-<triplet> is M-A:allowed rather than M-A:foreign and
which is why gcc-14-<triplet> depends on binutils-<triplet> without
adding :any. What is missing here is ensuring that gcc-14-<triplet>
actually uses binutils-<triplet> instead of using binutils (which may be
different).
The comment in debian/rules2 indicates that we are intentionally
skipping --with-as and --with-ld for the native toolchain. Adding them
would likely break stuff. I might even have done that in earlier patches
and maybe Matthias discarded that aspect. We have another tool at our
disposal: gcc looks up these tools in a toolchain-dependent search path.
In particular, it searches /usr/lib/gcc/<triplet>/<version> before
searching /usr/bin. What I am proposing here is that we place symlinks
there that point at the correct binutils.
You can locally verify this by messing with your filesystem:
ln -s /usr/bin/aarch64-linux-gnu-as /usr/lib/gcc/aarch64-linux-gnu/14/as
ln -s /usr/bin/aarch64-linux-gnu-ld /usr/lib/gcc/aarch64-linux-gnu/14/ld
Once you issue these in your container, stuff should work. So what my
patch does is adding these links to the package.
Matthias may ask why this is relevant. One goal of the -for-host work is
supporting native 32bit builds with 64bit cross toolchains. Particular
use cases are installing gcc-14-i686-linux-gnu:amd64 or
gcc-14-arm-linux-gnueabihf:arm64 in i386 and armhf chroots respectively
to be able to build software that otherwise would be exceeding its
address space limit. It is these situations where these symlinks become
relevant.
I don't want to apply this patch for trixie. Having these as and ld
symlinks in the gcc_lib_dir had other issues. The main reason for that
failure is installing the native arm64 compiler on amd64. Is there a
way to discourage installation of the native arm64 compiler in favor of
the arm64 cross compiler?
