Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Dependencies of linux-headers-<arch> packages
14 views
Skip to first unread message
Johannes Schauer Marin Rodrigues
Mar 3, 2022, 8:00:03 AM3/3/22
to
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/BY5PR04MB67876A933A...@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
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/BY5PR04MB67876A933A...@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
Ben Hutchings
Mar 7, 2022, 7:50:03 PM3/7/22
to
On Thu, 2022-03-03 at 11:13 +0000, Moessbauer, Felix wrote:
> Hi,
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.
> 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 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
> 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?
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.
Johannes Schauer Marin Rodrigues
Mar 10, 2022, 5:10:03 AM3/10/22
to
Hi Felix,
Quoting Moessbauer, Felix (2022-03-10 11:02:44)
> 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
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:
> >
> > 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.
> > but that is blocked by us not having enough time to work on
> > https://bugs.debian.org/666743
>
> 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
Helmut Grohne
Mar 13, 2022, 2:20:02 PM3/13/22
to
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
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
Helmut Grohne
Mar 14, 2022, 4:20:02 PM3/14/22
to
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
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
0 new messages