-
-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shared libraries are not built on Alpine Linux #180
Comments
Alpine Linux uses musl and the musl target in rust is assumed to require static-only builds. 3dc0c1e always set the target and 736a842 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 |
See here rust-lang/rust#82556 for the current status. |
I have tried
Looks like I could not use both arguments same time, right? |
|
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 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. |
this is also not true anymore: there's a lot of discussion there; the tl;dr is that nothing actually changed (backwards compat), and the |
I am a bit confused by the state of this problem. I thought that #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:
If I run this instead: $ cargo cbuild -p gst-plugin-hlssink3 --library-type staticlib --library-type cdylib it appears to ignore the
Following this comment, however, makes it seemingly work (and generate a
Can't it be fixed somehow such that this change in |
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 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 🙈. Maybe a "Troubleshooting" section in the README? I can open a PR if you want. |
Yes please, it would be more than welcome :) |
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.
The text was updated successfully, but these errors were encountered: