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
On Fri, 14 Feb 2025 at 11:59, Helmut Grohne <hel...@subdivi.de> 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.
>
> Helmut
>
