-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Description
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
- Checkout https://github.com/russelltg/link-dylib-to-staticlib
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]
Activity
ehuss commentedon Nov 22, 2023
Transferred to rust-lang/rust since the compiler is responsible for this.
I'm not sure how possible this is to support.
russelltg commentedon Nov 25, 2023
Fwiw, the Rust Reference explicitly says this is not supported
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 throughcargo rustc -- --print=native-static-libs
to get it added to the link. I think adding an absolute path to the.so
innative-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 likerusselltg commentedon Nov 25, 2023
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?