shared_flag and static_flag don't work

[glandium]

The -shared and -static flags are linkage flags, and don't do anything when passed alongside -c.

Taking the example from shared_flag:

cc::Build::new()
    .file("src/foo.c")
    .shared_flag(true)
    .compile("libfoo.so");

What that does is:

cc $OTHER_FLAGS -shared -o foo.o -c src/foo.c
ar cq libfoo.so.a foo.o
ar s libfoo.so.a

The first command is strictly equivalent to cc $OTHER_FLAGS -o foo.o -c src/foo.c. So in practice, it makes no difference whether shared_flag was passed or not, and compile("libfoo.so") would make you think you'd end up with a dynamic library, but you don't.

[jerry73204]

Is the issue intended to be fixed?

[ssh352]

how can I build dylib with cc crate?

[zhangzhuang15]

Same Problem.

[XuKeli8080174]

Same Problem too

[zhangzhuang15]

 你好 ，您发给我的邮件我已经收到。

[sladg]

Any solution to this one?

[NobodyXu]

This issue is due to cc always run ar, changing it should be possible.

cc @ChrisDenton @thomcc What's your thoughts on this?

[silvanshade]

Here's a workaround for this:

let out_dir = Path::new(std::env::var("OUT_DIR").unwrap());
let builder = cc::Build::new().file("src/foo.c");
let objects = builder.compile_intermediates();
builder
    .get_compiler()
    .to_command()
    .args(["-shared", "-o"])
    .arg(out_dir.join("libfoo.so"))
    .args(&objects)
    .status()
    .unwrap();

[Walter-Reactor]

Just following up here, this is doubly true on MSVC where the -shared flag actually triggers an error

[zhangzhuang15]

I've received your message, and will respond as soon as possible.

[madsmtm]

Heads up: This is being discussed in #1444.

Personally, I'm against having this feature in cc-rs, since it's complex to support correctly (for example, you'd want cc-rs to use the same linker as rustc, but when using e.g. RUSTFLAGS=-Clinker=rust-lld, we'd have to know how to pass the correct flags to the linker. And e.g. for correctness on at least macOS, we'd need to pass -platform_version. Might be possible to work around by passing -fuse-ld=rust-lld to the compiler driver? But even then, how do we then avoid nonsensical things like cc -fuse-ld=cc? Should we instead invoke rustc as the linker? But what if the user doesn't have rustc in their PATH?).

I'd be more in favour of someone creating a separate crate like linker-rs, and implementing the desired capabilities there (since linking is mostly orthogonal to compiling).

[NobodyXu]

Well yeah, having a separate crate might be more reasonable, given that we already expose enough API for them to use cc to do compiler detection/etc

Like we can expose some APIs useful for link-rs/dynlib-rs