Cannot link dylib crate to staticlib crate

[russelltg]

Problem

If you have a dylib-kind crate and try to use it from a staticlib-kind crate, you get this error:

error: crate `dylib` required to be available in rlib format, but was not found in this form

Steps

1. Checkout https://github.com/russelltg/link-dylib-to-staticlib
2. cargo build

Possible Solution(s)

Ideally metadata in the .lib would be generated to make the eventual target link to the shared library, I assume through the native-static-libs. It would be fine without this though, I'm fine with manually linking it.

Alternatively, if this is not a valid configuration, a better error message would be appreciated

Notes

My usecase is something I think should be supported--I'm writing a static library to be consumed from a C++ application, and it needs a tokio runtime that will be shared with other static libraries. So I've put the tokio runtime in the dynamic library.

My workaround for now is to make it a cdylib and not to mangle the function, and import it with an extern section.

Maybe there's a better way to do what I'm trying to do?

Version

cargo 1.73.0 (9c4383fb5 2023-08-26)
release: 1.73.0
commit-hash: 9c4383fb55986096b414d98125421ab87b5fd642
commit-date: 2023-08-26
host: x86_64-pc-windows-msvc
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 8.2.1-DEV (sys:0.4.65+curl-8.2.1 vendored ssl:Schannel)
os: Windows 10.0.19045 (Windows 10 Pro) [64-bit]

[ehuss]

Transferred to rust-lang/rust since the compiler is responsible for this.

I'm not sure how possible this is to support.

[russelltg]

Fwiw, the Rust Reference explicitly says this is not supported

If a static library is being produced, all upstream dependencies are required to be available in rlib formats. This requirement stems from the reason that a dynamic library cannot be converted into a static format.
Note that it is impossible to link in native dynamic dependencies to a static library, and in this case warnings will be printed about all unlinked native dynamic dependencies.

However, it does not seem impossible to get this to work (possibly I'm missing something here)--I would certainally not expect rust to somehow turn a dynamic library into a static one as the reference indicates, but just supply linker flags for the downstream buildsystem to link to the required dynamic library.

It seems propagation could work the same way rlibs are able to propagate #[link(name = "...")] attributes, which already supplies link flags through cargo rustc -- --print=native-static-libs to get it added to the link. I think adding an absolute path to the .so in native-static-libs would cover most usecases (lets downstream system decide how it will be finding the rust libraries at runtime). Not sure about non-Linux platforms.

So, for the link-dylib-to-staticlib example, running cargo rustc -- --print=native-static-libs would yield something like

note: native-static-libs: -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc path/to/link-dylib-to-staticlib/target/debug/libdy.so

[russelltg]

Ah, this exact thing is implemented in #106560 under an unstable flag, very cool!

Not sure if this should be closed considering I don't see any issue tracking this feature...

Edit: should the docs be updated to reference the flag? Or is it undocumented on purpose?