[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support

On 2023-02-15 15:37 -0700, Sam Hartman wrote:
> >>>>> "Fabian" == Fabian Grünbichler <debian@fabian.gruenbichler.email> writes:
>     Fabian> All in all it seems to me like the problem currently is more
>     Fabian> a theoretical one - it doesn't seem to cause (much, if at
>     Fabian> all) additional breakage on top of stuff that is already not
>     Fabian> cross compilable at the moment for other reasons.

I admit to not having studied this properly, but I think this is the
(farily) well-known 'multiarch interpreter' problem, when any arch-all
package in the dependency chain 'loses' the inherited 'host-arch'
value so all dependency resolution further down the chain is wrong.

This doesn't matter if everything further down the chain _is_
arch-independent, but as soon as you hit something where the arch
matters (e.g. a package which links to a C-library), stuff breaks.

> It seems like if a librust-* package depended on some system library it
> had a binding for, that's going to be a problem once the binding
> generation works cross-compiled.  Because if I'm understanding correctly
> once you manage to get onto the wrong architecture's dependencies, you
> will continue to use the wrong architecture.


> However, adding a question to the mix, why does arch all work for go
> packages?

Good question. I don't know anything about go, but I assume it has the
same problem as rust here, because it's also compiled and statically
linked. Maybe we package it defferently so there is never an arch-all dep above an arch-any dep in the dependency chain?

But in general this problem applies equally to any language where a dependency tree can have
in the stack (and the bottom one needs to be the host arch)

The rust form of this is slightly different because of the unusual
'source-included' scheme that rust's inability to dynamic-link has
forced upon us. But (unless I misunderstand) the fundamental issue is
the same.

The ultimate problem here is that multiarch was designed with a 'C'
mindset, so the assumption that architecture-dependencies would
propagate down the chain (or things were arch-independent all the way
further down) was implicit. The
actually-quite-common-in-other-languages pattern where things were
_mostly_ arch-independent (due to being an interpreted language, for
example), but some random library in the dependency-chain (at least 2
levels down) might actually be a wrapper for an arch-specific
C-library, was not considered in the design.

The 'fix' (a workaround) is to make any packages which appear as the
arch-all intermediaries in dep-chains to be made arch-any so that
chain is not broken. We can either do that for all packages in an
ecosystem, or just for ones that actually exhibit this problem. Doing
it for all is safer.


Principal hats:  Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature

Reply to: