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
diff --minimal -Nru gcc-14-14.2.0/debian/changelog
gcc-14-14.2.0/debian/changelog
--- gcc-14-14.2.0/debian/changelog 2025-01-30 08:50:29.000000000 +0100
+++ gcc-14-14.2.0/debian/changelog 2025-02-14 08:18:41.000000000 +0100
@@ -1,3 +1,10 @@
+gcc-14 (14.2.0-16.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Ensure that gcc calls as/ld of matching architecture. (Closes: #1083135)
+
+ -- Helmut Grohne <hel...@subdivi.de> Fri, 14 Feb 2025 08:18:41 +0100
+
gcc-14 (14.2.0-16) unstable; urgency=medium
* Update to git 20250130 from the gcc-14 branch.
diff --minimal -Nru gcc-14-14.2.0/debian/rules.d/binary-gcc.mk
gcc-14-14.2.0/debian/rules.d/binary-gcc.mk
--- gcc-14-14.2.0/debian/rules.d/binary-gcc.mk 2024-01-19 16:06:34.000000000
+0100
+++ gcc-14-14.2.0/debian/rules.d/binary-gcc.mk 2025-02-14 08:18:40.000000000
+0100
@@ -129,6 +129,12 @@
dh_link -p$(p_gcc_n) \
/$(gcc_lexec_dir)/liblto_plugin.so
/$(gcc_lib_dir)/liblto_plugin.so
+ # Point gcc at binutils of matching architecture
+ dh_link -p$(p_gcc_n) \
+ /usr/bin/$(DEB_TARGET_GNU_TYPE)-as /$(gcc_lib_dir)/as
+ dh_link -p$(p_gcc_n) \
+ /usr/bin/$(DEB_TARGET_GNU_TYPE)-ld /$(gcc_lib_dir)/ld
+
# dh_installdebconf
debian/dh_doclink -p$(p_gcc_n) $(p_xbase)
