Re: installing foreign architecture linux-headers-*
Hi Andreas,
On Fri, Feb 23, 2024 at 01:57:23PM +0100, Andreas Beckmann wrote:
> since you have been digging deeper in cross-building etc. maybe you have an
> idea here.
I prefer being contacted about cross building matters via
debian-cross@lists.debian.org. Given your explicit agreement, I bounced
your mail there.
> These tests were triggered by https://bugs.debian.org/1042993
> "dkms: DKMS fails to build amd64 kernel module in i386 userland"
>
> In bookworm/i386 the following was working:
>
> dpkg --add-architecture amd64
> apt-get update
> apt-get install dkms linux-headers-amd64
> apt-get install some-dkms
>
> and the some.ko kernel module was built for the -amd64 kernel on i386.
>
> At some point (probably around linux 6.4) dependencies changed, the above
> foreign mixture was still installable but building the module started to
> fail ("x86_64-linux-gnu-gcc-13: not found", #1042993)
I think Bastian Blank significantly restructured the linux source
package at that time. I don't have a deeper understanding what changed
there beyond linux-libc-dev, which should be irrelevant here.
> As of today, in sid the kernel, compiler and binutils dependencies have
> changed significantly. Now installing linux-headers-amd64:amd64 on i386
> wants to replace binutils:i386 with binutils:amd64 etc. I've tried to lower
> the Depends: "gcc | c-compiler" in dkms to a Recommends (linux-headers-*
> should bring the correct compiler dependency anyway), but that didn't
> improve things ...
>
> Do you have an idea what would need to be changed to make the foreign -amd64
> headers again installable (and the modules buildable) without removing the
> i386 userspace?
I fear, I cannot provide much insight on the dkms/linux side of
matters, but I know that others on the list are regularly cross building
linux. However, I can give details on the gcc/binutils side of things.
A longer while back in a Paris sprint, we drafted a way to expressing
toochain dependencies. Examples for toolchain packages are binutils,
gcc, g++, but also pkg-config. The common theme is that we sometimes
need to prefix their tools with an architecture to get a different build
of them. To solve this, we devised package suffixes -for-build and
-for-host. Then you have four ways to depend on a toolchain package:
* $toolchain-$triplet: You must invoke prefixed tools with the prefix
spelled out in the package name and that prefix determines the
architecture you are producing code for. What you get may be a native
compiler or a cross compiler.
* $toolchain-for-build: You should invoke unprefixed tools. The
architecture this is generating code for is left unspecified beyond
being able to run this on the build system CPU. Typically this
produces code for the native architecture.
* $toolchain-for-host:$arch: Same as $toolchain:$triplet where the
architecture is turned into the matching triplet. Again, you may get
a native or a cross compiler.
* $toolchain: You may invoke the compiler with or without architecture
prefix and your package will be unsatisfiable in a cross building
context.
For some packages such as pkg-config or qmake-qt5 the story is
simplified. When you depend on them, you immediately get both the
unprefixed and the prefixed tools without having to append any
-for-build or -for-host.
Wht you see above is using a dependency on "binutils" without such a
suffix. This This is known to break cross build dependency resolution.
Eventually, a -for-build or -for-host suffix should be added there.
In bookworm, we have binutils with -for-build/-for-host suffixes, but
not gcc. This doesn't buy us much, because we often depend on gcc rather
than binutils and since gcc installs a bfd plugin, it needs some control
over the architecture binutils is running as.
Very recently, we added -for-build/-for-host packages for gcc in
unstable. This also comes with new -$DEB_HOST_GNU_TYPE:$DEB_HOST_ARCH
packages that were missing earlier. If you were to depend on
gcc-12-x86-64-linux-gnu in bookworm, you'd only ever get a cross
toolchain via multiarch, but never a native amd64 toolchain. In trixie
and later, these are extended to cover the native case as well.
Arguably, linux-compiler-gcc-13-x86:amd64 should depend on
gcc-13-x86-64-linux-gnu, gcc-13-for-build rather than gcc-13 (and
linux-compiler-gcc-13-x86:i386 likewise gcc-13-i686-linux-gnu,
gcc-13-for-build). This may be the change that is missing to make things
work for you.
I note that the -for-build/-for-host work for gcc in trixie/sid still
has problems. For instance, gcc-for-host still has too tight version
restrictions that do not actually permit using cross toolchains yet. If
you say gcc-for-host in unstable now, you only ever get a native
toolchain, but this is something I want to change.
What I wrote may leave question marks. Don't hesitate to ask for more
details. Having more people understand these matters can only be
beneficial as we need to annotate quite a number of dependencies with a
triplet or -for-{build,host}. Thanks for bearing with me.
Helmut
Reply to: