cargo-c
cargo-c copied to clipboard
Shared libraries are not built on Alpine Linux
Tried to build rav1e 0.4.1 with cargo-c 0.8.0 on Alpine Linux and got no any .so libraries built. I was expecting to get: librav1e.so.0 and librav1e.so.0.4.1.
rav1e 0.4.0 with cargo-c 0.7.1 build them without any problem.
Actually it is not a problem, I am just curious to find out the origin of this change in behavior and to know what to expect in future builds as I used to have a separate package for shared libraries.
Alpine Linux uses musl and the musl target in rust is assumed to require static-only builds.
https://github.com/lu-zero/cargo-c/commit/3dc0c1e66ae8435449f8e650a0ed2ccdad3f9ffe always set the target and https://github.com/lu-zero/cargo-c/commit/736a84292d4d90849cdf71621f8caee49c3dff22 defaults to static-only if not otherwise stated.
In theory the newer rustc (maybe still nightly) would have a specific target for musl+shared-library that would make the default work as you expect. For now passing --library-type staticlib,cdylib
should produce the .so on Alpine.
See here https://github.com/rust-lang/rust/pull/82556 for the current status.
I have tried --library-type staticlib,cdylib
but got following error:
692 error: 'staticlib,cdylib' isn't a valid value for '--library-type <LIBRARY-TYPE>...'
693 [possible values: cdylib, staticlib]
694 Did you mean 'staticlib'?
695USAGE:
696 cargo-cbuild cbuild --frozen --library-type <LIBRARY-TYPE>... --prefix <prefix> --release
Looks like I could not use both arguments same time, right?
--library-type staticlib --library-type cdylib
sorry.
Thank you for a tip, checking now the build...
Works great! Thank you so much for you kind attention and help!
Once cargo is able to tell the difference between musl-with-dylibs and musl-without it will work out of box. :)
This is a mistreatment of the musl target we're trying to get fixed in upstream Rust. Like any other platform with dynamic linking, linux-musl target should produce dynamic binaries by default and support the production of shared libraries, and only do static linking when a static-linked binary is requested.
this is still broken, even though the $arch-alpine-linux-musl
target does not default to static libraries, and we configure the target to build dynamic by default.
the code does not respect this:
let default_kind = || match (rustc_target.os.as_str(), rustc_target.env.as_str()) {
("none", _) | (_, "musl") => vec!["staticlib"],
_ => vec!["staticlib", "cdylib"],
};
defaulting to static in every -musl configuration.
and the musl target in rust is assumed to require static-only builds.
this is also not true anymore:
https://github.com/rust-lang/rust/pull/40113
there's a lot of discussion there; the tl;dr is that nothing actually changed (backwards compat), and the $arch-unknown-linux-musl
toolchains and targets still assume +crt-static by default (like the ones from rustup), but this is not 'supposed' to be the case, and other triples don't necessarily follow this (just like in C, having a different triple implies different behaviour; gating things behind *-musl is not correct if the things are not indeed specific to musl itself.)
I am a bit confused by the state of this problem. I thought that https://github.com/lu-zero/cargo-c/pull/268 would fix it, but in my experience on Alpine (with cargo-c v0.9.28) it doesn't seem like it is.
In my case, running the following:
$ cargo cbuild -p gst-plugin-hlssink3 --library-type cdylib
complains with:
Error: CliError { error: Some(cannot produce cdylib for
gst-plugin-hlssink3 v0.12.0-alpha.1 (/home/user/gst-plugins-rs/net/hlssink3)
as the targetx86_64-unknown-linux-musl
does not support these crate types), exit_code: 101 }
If I run this instead:
$ cargo cbuild -p gst-plugin-hlssink3 --library-type staticlib --library-type cdylib
it appears to ignore the cdylib
with:
warning: dropping unsupported crate type
cdylib
for targetx86_64-unknown-linux-musl
Following this comment, however, makes it seemingly work (and generate a .so
):
# .cargo/config
[target.x86_64-unknown-linux-musl]
rustflags = [
"-C", "target-feature=-crt-static",
]
Can't it be fixed somehow such that this change in .cargo/config
is not necessary? Any pointer is appreciated :-).
if you build your own rustc you can change the default, but if it is the rustup-provided, you need that I think.
Oh, my mistake was to install rust with rustup
. Using the Alpine package (apk add rust cargo
) just works :+1:. I guess it's handled by something like this?
Good to know, thanks for the help!
Can I add some documentation about it and we could close this issue? :)
Not sure where that would go. It's not about installing cargo-c, it's really about rust. I should have known better than installing it with rustup in the first place :see_no_evil:.
Maybe a "Troubleshooting" section in the README? I can open a PR if you want.
Maybe a "Troubleshooting" section in the README? I can open a PR if you want.
Yes please, it would be more than welcome :)