Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
On February 15, 2023 8:57:12 PM GMT+01:00, Sam Hartman <hartmans@debian.org> wrote:
>>>>>> "Fabian" == Fabian Grünbichler <debian@fabian.gruenbichler.email> writes:
>
> Fabian> On Wed, Feb 15, 2023, at 7:51 PM, Fabian Grünbichler wrote:
> >> Hi,
> >>
> >> I'm writing this mail in order to get further input from
> >> knowledgeable, but not directly involved DDs - mostly those
> >> involved with cross-building and multi-arch matters.
>
> Fabian> sorry for the noise - now with correct CC of
> Fabian> debian-cross@lists.debian.org, instead of the mis-pasted
> Fabian> d-cross@ ..
>
>A couple of questions that aren't obvious to me:
>
>1) Is my understanding generally correct that it mostly doesn't matter
>if you get the wrong architecture's package for a rust library package,
>since it's the same source code in both cases?
For librust-*, yes, unless something requires special treatment they'll be identical across the architectures, and such special circumstances are usually limited to bin crates.
>2) When does it matter which architecture's packages you get for rust
>library packages?
Same as above - unless the package in question has some custom rules/install files, it never should, except for transitive effects on stuff outside of librust-*.
>3) When do rust library packages have dependencies on other kinds of
>packages--packages that have more than source code?
This mainly happens with crates (dynamically) linking to C libraries (or C bindings to libraries written in other languages). By convention these end in -sys, and when packaged for Debian, will mostly generate the needed Rust binding code at build time using the bindgen crate/tool - but build time here means both building of the rust-foo-sys crate itself, as well as any (transitive!) reverse dependency (again, because the Rust part will be statically linked).
Like I said in the original mail, bindgen is currently not working in a cross compilation scenario because the required clang packages don't seem to be co-installable (rustc which is the cross compiler in that case itself also depends on libllvm).
There are other cases as well, like -sys crates with manually written bindings that don't use bindgen, or other code that uses arch-specific non Rust things that might not be there/in the wrong path/have the wrong content when a package from the wrong arch is pulled in. E.g. besides the clang-related failures there's also one involving cython that I haven't fully analyzed yet. And of course, there might be things that compile/build but are in fact broken.
All in all it seems to me like the problem currently is more a theoretical one - it doesn't seem to cause (much, if at all) additional breakage on top of stuff that is already not cross compilable at the moment for other reasons. It does seem like a step in the wrong direction though.
Reply to: