Hi Felix,

Quoting Moessbauer, Felix (2022-03-03 12:13:34)

the kernel header packages have a dependency to c/c++ compilers. E.g. the "linux-headers-5.10.0-10-arm64" package depends on gcc-10:arm64 -> cpp-10:arm64 (on bullseye).

This becomes an issue when cross-compiling kernel modules for other target architectures:

instead of "target" you probably mean "host" architecture. The GNU terminology is "host" for the architecture you build for and "target" for the architecture that the compiler you build compiles binaries for. Since you are not building a compiler you want to use either host or build architecture. The terminology is explained in the dpkg-architecture man page.

The linux-headers packages cannot be co-installed due to the not co-installable cpp-<x> packages.

By that, cross-compilation of kernel modules for other Debian targets is currently not possible (at least without removing the hosts cpp infrastructure).

What is the reason to depend on compilers here?
Wouldn't be a "recommends" relation be sufficient here?
An alternative might also be to depend via `:native`, but I did not check that yet.

You cannot add :native to runtime dependencies. The :native qualifier only makes sense for build dependencies. See https://wiki.ubuntu.com/MultiarchCross

You can find the answer to your question in this thread:

https://lists.debian.org/BY5PR04MB67876A933A82670BD934DEB2E4C89@BY5PR04MB6787.namprd04.prod.outlook.com

Essentially, linux-headers-* should depend on gcc-10-for-host:arm64 but that is blocked by us not having enough time to work on https://bugs.debian.org/666743

Fixing #666743 would be a major step forward in terms of making packages cross-compilable on Debian and derivatives, so if you want to improve the cross-building situation in Debian, then this is one of the big open tasks that would bring us immensely forward.

Thanks!

cheers, josch
--==============†72012295255188870=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmIgu7EACgkQ8sulx4+9 g+GowRAAra9RrB7jClq/5QQOuRFeHXlQaufdz8lDTrC4AiyJdZ5/a84SY9Z635jG QtKbuf1epk4cQ41HX3PXjrDy70jSFGOGo2ZIgYyF0RMZVCYLLRuN8u4ZrC4fbs8q x8wV/Ddd+PpZY/lpQ447u/LnjWhpz1KsDIOdjx4MV7BHLdr2w+1zJ/NRKjoeQ1CL hh/2Z+Vh3Zfl9/t4FYNMXnxe3S1ATGrdoNbO4NewEra7rGdM0LwlIIau+tcFkucC Mes5BH6CUKDvIw5xLcwBPt6o7rjuk9nw2JvYrltto+h4e5pql+8s3CsxjeToYxdz J91iYkIgKfbRrvgRmYuPgrPyv0nNXbKMx3eD6aVbg47zSIcFN3OsavtA+XSSZxcq quXdF3wGQ/DmP9ynsk4pf7mVNS1tZ528yo84OphjQcW4XLDnmAh4sO0WMR0iylsR fw8DVxa1PCTyZR3KSVlusVFkDveaRJp0kiEJiHwO0Awys4/mC1RPRrSnzE+qOJuz /8g1pkMtMkS/9rlpYhnU3kfLqQFyBEz4U3qp9Uus01TAGWyxMsv7BGiM6dRnILS1 r4iLKRV8qY8aI6Drec5D3yPn7Des8hFb6gEcQ1/IE8HSkTwRkYNY19mveRpFytY6 H1esTtMpy+Ns67+op9r+VeIYSI8m/EYe8I82bTT7X6mU00KuZyk=
=xzK3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

--=-5cVXMufNurcwL7/D+DWz
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2022-03-03 at 11:13 +0000, Moessbauer, Felix wrote:

Hi,

the kernel header packages have a dependency to c/c++ compilers.
E.g. the "linux-headers-5.10.0-10-arm64" package depends on gcc-
10:arm64 -> cpp-10:arm64 (on bullseye).

This becomes an issue when cross-compiling kernel modules for other
target architectures:
The linux-headers packages cannot be co-installed due to the not co- installable cpp-<x> packages.

By that, cross-compilation of kernel modules for other Debian targets
is currently not possible (at least without removing the hosts cpp infrastructure).

What is the reason to depend on compilers here?

We want installation of OOT modules to be as simple as possible for
those users that need it. A dependency makes this more robust.

Wouldn't be a "recommends" relation be sufficient here?
An alternative might also be to depend via `:native`, but I did not
check that yet.

[...]

Using :native would defeat the purpose. But the attached patch
(untested) might fix the dependencies to allow for cross-compilation.

linux-kbuild does have some support for use in cross-compilation but I
don't know how well it works now.

Ben.


--
Ben Hutchings
Q. Which is the greater problem in the world today,
ignorance or apathy?
A. I don't know and I couldn't care less.

--=-5cVXMufNurcwL7/D+DWz
Content-Disposition: attachment;
filename*0 01-linux-headers-Fix-compiler-dependencies-to-allow-for.pat;
filename*1=ch
Content-Type: text/x-patch;
name="0001-linux-headers-Fix-compiler-dependencies-to-allow-for.patch";
charset="UTF-8"
Content-Transfer-Encoding: base64

RnJvbSBlZDg3MGRmM2MwYWIzZDYwYWE2MGNmNTA5ZWU2YzNkMTBhYjQxMjc2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCZW4gSHV0Y2hpbmdzIDxiZW5oQGRlYmlhbi5vcmc+CkRhdGU6 IFR1ZSwgOCBNYXIgMjAyMiAwMDo0NDozOCArMDEwMApTdWJqZWN0OiBbUEFUQ0ggbGludXhdIGxp bnV4LWhlYWRlcnM6IEZpeCBjb21waWxlciBkZXBlbmRlbmNpZXMgdG8gYWxsb3cgZm9yCiBjcm9z cy1idWlsZHMKVG86IGRlYmlhbi1rZXJuZWxAbGlzdHMuZGViaWFuLm9yZwoKLS0tCiBkZWJpYW4v Y2hhbmdlbG9nICAgICAgICAgICAgfCA2ICsrKysrKwogZGViaWFuL2NvbmZpZy9hbWQ2NC9kZWZp bmVzIHwgMiArLQogZGViaWFuL2NvbmZpZy9hcm02NC9kZWZpbmVzIHwgMiArLQogZGViaWFuL2Nv bmZpZy9hcm1lbC9kZWZpbmVz

Hi Felix,

Quoting Moessbauer, Felix (2022-03-10 11:02:44)

You cannot add :native to runtime dependencies. The :native qualifier only makes sense for build dependencies. See https://wiki.ubuntu.com/MultiarchCross

You can find the answer to your question in this thread:

Essentially, linux-headers-* should depend on gcc-10-for-host:arm64
but that is blocked by us not having enough time to work on https://bugs.debian.org/666743

Ok, got it. But what about the workaround proposed by Ben Hutchings.
Looks like this fixes the cross compiling, until #666743 is resolved.
IMHO it is also a better workaround than just removing the dependencies as suggested in the mail thread.

if you can test Bens patch and the Linux maintainers are willing to apply it then I guess you found a much simpler solution to your problem than #666743 :)

Thanks!

cheers, josch
--==============$14828703644026276=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmIpzf0ACgkQ8sulx4+9 g+EVpg/+P5vjekizYEzN4S4JruF043RqcgaVFmNjO3u9d8y/w20mx44r3HyajoX5 rPZgL1p4N8zz+Ks2fY4ZH+wDunLsHZUEtSgV0eX1IQmuIkkHiiuuacEfl8ROP7V9 w3MumDPkb1U6tMj6tVx8zGsl83qJM9fJerNvJHLhBzdm+yO/Pn97a1sgbGZt6cPD Va04X3YqwWVxcEjKLxu8a8RB2T4clqvYX2CWozU9/9BRPg93pXwhfX9XvBNwgJsG SiJ9Z0v4GJSY/9MU+2aVrXw1TX2Hsk+4pKBgVw9In5jtpV7T3hBkFb016lzIyxbP l47gEcotUNkqL7zhbumF97I/gVxzkhI0TlMSlrdv/8XulmMnY4n2LdKs9k2LkT6x IdbUjuBnAcUKdM4uUHXqUPkWBUV5eYarwMWZT9G/6ja6AoJUOAZDGxtNe3eGCBPw k7helYuab53uQ/W+4vFYkRRfefwm5C23bT+kcFqPHxZFDC9PKxZpdQexJVdXBHQ/ Hn2+BACydrEVEKoBPQxQqEHMHOWn1bSuhz3eNVlXJpMB9S9fFG78+yFYbiJihiKv +XVfYO1FoYxDCthct3x40uuOuiDmWcrUA6bfRlFcqZ5Pe85Fby6HHBptK5bC1Du4 YW/4q+vaE/FzrM0Ibdx3Y/jOl50w6mXjXGi1U6H1vpb+Op0wicQ=
=cQNR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Thu, Mar 10, 2022 at 02:13:34PM +0000, Moessbauer, Felix wrote:

Many thanks for the patch.
I just (manually) backported that to Debian bullseye, tested it for arm64 and it worked like a charm.

Can we please stop piling up workarounds and instead fix this once and
for all?

I see us mirroring the "LTS problem" here: Everyone maintains their own
stuff with local patches and it barely works. LTS now has a solution in
the form of freexian where the effort is centralized and made available
for the benefit of everyone.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Felix,

On Mon, Mar 14, 2022 at 10:33:22AM +0000, Moessbauer, Felix wrote:

In general I agree, but here the situation is a bit different:
The dependency to the host compiler (e.g. arm64) is too narrow.

Wrong. It certainly is not and beyond that, this aspect is not weakened.
It still requires a particular version of gcc for the relevant
architecture.

In general, any gcc compiler in the correct version should do.

Wrong. Ben explained why this is not desired and his patch does not
relax this aspect.

As discussed earlier the linux-headers -> compiler dependency is just a convenience dep.
I proposed to remove it or move it to the "recommends" section.

Yes, you proposed that. But it was not an accepted solution and it is
not what Ben's patch does.

But the proposed solution might be better as it maintains backwards compatibility.

Ben's solution is a workaround. The linux packaging is already complex
in this regard. We need to reduce complexity, not add to it.

For users that just want to cross-compile a module, there is simply no reason why the have to install the compiler for the host architecture (e.g. arm64).

The essence of cross compilation is a compiler that targets the host architecture. Of course, you do need it for cross compiling a kernel
module.

And this use-case is perfectly solved in the patch from Ben.

We seem to be in disagreement of what "perfect" means. Any time, you
iterate over architectures in your dependencies, things are certainly
not perfect as every new architecture will require manual work. Manual per-architecture work does not qualify as "perfect" to me. While it
solves your use case, it incurs a maintenance cost where a solution with
less cost is available.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)