Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

On my system, the cross compiler 'gcc-14-aarch64-linux-gnu:arm64' is
installed on Trixei using amd64.
My guess is that the build configuration of the cross compiler uses the
local assembler, instead of the aarch64 cross assembler.
When using the cross compiler on arm64 architecture, everything seems to
work.
But once using the cross compiler on a different architecture, the error
appears.

Erez

please provide a reproducible example what exactly doesn't work for you.

please provide a reproducible example what exactly doesn't work for you.

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'

That's all.

Erez

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'

That's all.

Erez

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'

That's all.

Erez

As the cross compiler is not working at all.
The severity should be serious.
The fact that the compiler works on the arm64 platform is irrelevant, the
package is intended for cross compilation.
It must work on foreign architectures.

Erez

Checking compiler configuration
The cross compiler is definitely calling the host assembler instead of
calling the cross assembler.

root@098d058969e7:~# aarch64-linux-gnu-gcc  --version -v
Using built-in specs.
COLLECT_AS_OPTIONS='--version'
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-linux-gnu/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
aarch64-linux-gnu-gcc (Debian 14.2.0-3) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 14.2.0-3'
--with-bugurl=file:///usr/share/doc/gcc-14/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust
--prefix=/usr --with-gcc-major-version-only --program-suffix=-14
--program-prefix=aarch64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/libexec
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace
--enable-gnu-unique-object --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror
--enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-14-14.2.0/debian/tmp-nvptx/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu
--target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-serialization=4
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (Debian 14.2.0-3)
COLLECT_GCC_OPTIONS='--version' '-v' '-mlittle-endian' '-mabi=lp64'
'-dumpdir' 'a-'
 /usr/libexec/gcc/aarch64-linux-gnu/14/cc1 -quiet -v -imultiarch
aarch64-linux-gnu help-dummy -quiet -dumpdir a- -dumpbase help-dummy
-mlittle-endian -mabi=lp64 -version --version -fasynchronous-unwind-tables
-o /tmp/ccBH4ooT.s
GNU C17 (Debian 14.2.0-3) version 14.2.0 (aarch64-linux-gnu)
        compiled by GNU C version 14.2.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.27-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='--version' '-v' '-mlittle-endian' '-mabi=lp64'
'-dumpdir' 'a-'
 *as* -v -EL -mabi=lp64 --version -o /tmp/ccKrhpvd.o /tmp/ccBH4ooT.s
GNU assembler version 2.43.1 (*x86_64-linux-gnu*) using BFD version (GNU
Binutils for Debian) 2.43.1
as: unrecognized option '-EL'

root@098d058969e7:~# aarch64-linux-gnu-as --version -v
GNU assembler (GNU Binutils for Debian) 2.43.1
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `aarch64-linux-gnu'.

root@098d058969e7:~# as --version -v
GNU assembler (GNU Binutils for Debian) 2.43.1
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-linux-gnu'.

Hi,

I am not sure, but perhaps the issue comes from:

configure has a flag for cross compiling.
If '--build' '--host' ant '--target' have the same value then we do not use
cross compiling.
Although cross compiling refers to the build itself,
 it seems it affects the result compiler as well.
As the compiler is not cross, it calls the host assembler.

I am not sure what is the proper way to fix this, but I can think of two
ways.
Building on a different machine,
 So '--host' and '--target' are arm64, but '--build' is not.
Or make sure the compiler calls the assembler with the prefix.
A change that may require a patch.

Anyhow as I already mentioned this is a serious issue and a stopper.
As the compiler is NOT cross.

Thanks
   Erez

Control: retitle -1 gcc-VER-TRIPLET may use binutils for a different architecture
Control: severity -1 important
Control: tags -1 = confirmed patch

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.

Helmut

Yes, you are right.

Removing gcc-14-aarch64-linux-gnu:arm64 does solve the problem.
It was installed by dependencies.
I am using multiple architectures for cross compilation.

My real question is why do we have gcc-14-aarch64-linux-gnu:arm64 in the
pool?
Cross compilers using the same host and target architecture are not really
cross.

In plain English this package (and similar to this) should not be in the
pool.
When building the cross compilers, the target and the host should not be
identical.

Erez Geva

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?

Hi Matthias,

Fair enough. However, we need some mechanism to redirect gcc into using
the "right" as and ld, which is not /usr/bin/{as,ld}. You already ruled
out --with-as earlier. This is particularly important for using "reverse
cross compilers" to alleviate the address space problem on 32bit. It
would help a lot if you could remember what those issues were.

It already is discouraged. gcc-VER-TRIPLET is marked M-A:foreign.
Therefore apt prefers the native package over the foreign one. sbuild
now configures APT::BarbarianArchitectures to fully forbid the foreign
native compiler. To be really strict, we could add a dependency on
"native-architecture" to the native toolchains. However, that bears a
risk of inducing temporary installability issues when it is uploaded.

Helmut

It's the native compiler used for natively building arm64 packages.
Without it, we cannot build any packages on arm64.

It's not a cross compiler. It's a native compiler.

Of course it should. Removing it amounts to removing the entire arm64
architecture.

I suppose the problem you are facing here is that Debian now blends the
cross and native toolchains together. There is gcc-14-aarch64-linux-gnu
as a package name and it says that it is building for aarch64-linux-gnu.
What it does not say is whether that's done using a cross or native
compiler. From a packaging dependency pov, you no longer can depend on a
cross toolchain. You merely can depend on a toolchain targeting a
particular architecture.

Of course you usually don't want the native toolchain for a foreign
architecture. If a package is declared M-A:foreign (such as is the case
with toolchains), you usually want the native one. You can tell apt
about this:

    APT::BarbarianArchitectures {"arm64"};

Once you do it, it'll refuse installing gcc-14-aarch64-linux-gnu:arm64,
but still allow installing gcc-14-aarch64-linux-gnu:amd64 which really
is a cross toolchain.

Helmut

Control: affects -1 + varnish

I have discovered that this bug also affects varnish, which calls
triplet-gcc at run time to build shared objects that it links to itself,
and now fails because there is no dependency which pulls /usr/bin/as.
I will make it depend on binutils for trixie to make it work at least
for the common case.

We are facing the same issue when migrating our dockerfile from debian 12 to 13.

We install the compiler like this:
```
FROM build-0 as build-util-linux-amd64
ENV HOST=x86_64-linux-gnu

FROM build-0 as build-util-linux-arm64
ENV HOST=aarch64-linux-gnu

FROM build-util-linux-$TARGETARCH as build-util-linux
RUN apt-get update && apt-get install -y gcc-${HOST//_/-}
```
And always call the triplet gcc, so that our dockerfile can build on any arch
for any arch.

Can you be specific why we can't use --with-as for native compiler?

If we really can't, can we at least make gcc-14-x86-64-linux-gnu depends on
binutils on amd64 (rather than binutils-x86-64-linux-gnu), so that it will not
complain on missing /usr/bin/as?

this is partially fixed in gcc-15 15.2.0-4:

   * Update the gcc-search-prefixed-as-ld patch to find the correct as.
     Still needs an update for collect2.cc. Addresses: #1113854.