Shared libraries are not built on Alpine Linux

[OTLabs]

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.

[lu-zero]

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 --library-type staticlib,cdylib should produce the .so on Alpine.

[lu-zero]

See here rust-lang/rust#82556 for the current status.

[OTLabs]

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?

[lu-zero]

--library-type staticlib --library-type cdylib sorry.

[OTLabs]

Thank you for a tip, checking now the build...

[OTLabs]

Works great! Thank you so much for you kind attention and help!

[lu-zero]

Once cargo is able to tell the difference between musl-with-dylibs and musl-without it will work out of box. :)

[richfelker]

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.

[nekopsykose]

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.

[nekopsykose]

and the musl target in rust is assumed to require static-only builds.

this is also not true anymore:
rust-lang/rust#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.)

[JonasVautherin]

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:

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 target x86_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 target x86_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 :-).