Is the issue intended to be fixed?

how can I build dylib with cc crate?

Same Problem.

Same Problem too

Any solution to this one?

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

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

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();

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

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).

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