search

mmstick / cargo-deb

A cargo subcommand that generates Debian packages from information in Cargo.toml
615 stars 50 forks source link

Provide cross-compile $auto library support #117

Open joelgallant opened 4 years ago

joelgallant commented 4 years ago

Currently, cargo-deb uses ldd statically, which will not work on a non-native target arch. The behavior of this could be emulated, as far as I'm aware.

I'd be open to help work on this with some guidance on best steps.

kornelski commented 4 years ago

Yeah, support for deps in cross-compilation would be great. What does it require?

joelgallant commented 4 years ago

If I understand cargo-deb's usage of ldd at the moment, it could be emulated with the target-specific readelf, grep for Shared library, pass those into locate, pass that into dpkg -S to find the apt package source? I'm not confident that that's a robust mechanism, but it's probably the same as the ldd method there is now.

ludiazv commented 4 years ago

I run cargo deb inside docker image of the target machine. For example if I'm packing for a arm64 i use a image using arm64v8/rust:1.43-slim-buster base image. Cargo deb runs target arch and should resolve the correct dependencies.

kornelski commented 4 years ago

Using readelf seems like doing it "the hard way". I hoped there would be something like cross-arch version of ldd and/or a flag in dpkg to look for a different arch.

gabrik commented 3 years ago

Any update on this?

Can't rely on readelf or objdump for discovery the dependencies instead of ldd?

I guess readelf or objdump can be specified for each architecture in the ./cargo/config.toml

We are running our build in a Jenkins that already uses a container, therefore we cannot spawn another container just for the .deb generation.

kornelski commented 3 years ago

I'm not working on this. It probably won't be done.

gabrik commented 3 years ago

I can try to give it some time. Once I have something working I'll do a PR.

kornelski commented 3 years ago

That would be great, thanks.

Maybe you could use a Rust elf parsing library instead of shelling out to readelf/objdump?

H-M-H commented 3 years ago

I just stumbled across this trying to fix another issue. I had a look at the linked elf parser and implemented a function that extracts the needed shared libs: https://github.com/mmstick/cargo-deb/issues/170#issuecomment-820574508 This only returns the names of those libs, not a path to their location. But one still could use dpkg -S to locate the required packages as it does not only include exact matches. So some more filtering of the result of dpkg -S probably needs to be done. Alternatively if not cross compiling, using ldd to find the exact library path will still work. Additionally a look at apt-file may be worth it as it does not require packages to be installed to search for matching files.

ryankurte commented 3 years ago

there's a wee interaction with cross here too (related to https://github.com/mmstick/cargo-deb/issues/99), if you compile in cross then run cargo deb outside of cross the $auto deps seem to resolve incorrectly, which not hugely surprising because it's a different ldd...

not sure there's a reasonable way to fix it, but it's easy-ish to manually specify the deps to avoid the problem. i figured i'd post here in case it helps someone else in the same basket.