I have a crate with dylib dependency. cargo test --lib works perfectly, but cargo test gives an error "can't find crate" for that dynamic crate. Is there any workaround?
I'm not sure that this issue is related to cargo, sorry if it is the wrong place.
Thanks for the report! Could you post an example project skeleton and the logs of what happens?
The project looks the following way:
foo
โโโ Cargo.toml
โโโ inner
โย ย โโโ Cargo.toml
โย ย โโโ src
โย ย โโโ lib.rs
โโโ src
โโโ lib.rs
inner/Cargo.toml:
[package]
name = "inner"
version = "0.1.0"
[lib]
crate-type = ["dylib"]
src/lib.rs:
extern crate inner;
Cargo.toml:
[package]
name = "foo"
version = "0.1.0"
[dependencies]
inner = { version = "0.1.0", path = "inner" }
Other files are empty.
Successful build and tests:
$ cargo test --lib
Compiling inner v0.1.0 (file:///home/stkach/code/1/foo/inner)
Compiling foo v0.1.0 (file:///home/stkach/code/1/foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.80 secs
Running target/debug/deps/foo-b72f13a1f670b904
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Failed build output:
$ cargo test --doc --verbose
Fresh inner v0.1.0 (file:///home/stkach/code/1/foo/inner)
Fresh foo v0.1.0 (file:///home/stkach/code/1/foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Doc-tests foo
Running `rustdoc --test /home/stkach/code/1/foo/src/lib.rs --crate-name foo -L dependency=/home/stkach/code/1/foo/target/debug/deps --extern foo=/home/stkach/code/1/foo/target/debug/deps/libfoo-e992780bc3c3e994.rlib`
error[E0463]: can't find crate for `inner`
--> /home/stkach/code/1/foo/src/lib.rs:1:1
|
1 | extern crate inner;
| ^^^^^^^^^^^^^^^^^^^ can't find crate
error: aborting due to previous error(s)
thread '<unnamed>' panicked at 'Box<Any>', /checkout/src/librustc_errors/lib.rs:514
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: test failed, to rerun pass '--doc'
Ah sorry I'd have to dig in more to see what's going on, but I don't have time right now :(
In case someone else stumbles here, this and #3178 can be solved (or atleast worked around) by specifying "plugin = true" in the dylib's [lib] section (in this case in "inner"). I tried to check if it could be enabled automatically for dylibs, but an initial solution (forcing Target.for_host to be true for dylibs) broke cross compiling for dylibs. I have some progress done in https://github.com/jgke/cargo/tree/always-compile-dylibs, but I don't know how this should be actually solved.
I'm also running into this issue. My use case is that I'm working with Elixir bindings via https://github.com/rusterlium/rustler, which requires that its compiled as a dylib.
I'm having this problem too.
In fact, I'm having trouble finding any example online of someone actually getting dylib to work, in any circumstance. I'd love to see a minimum, barebones happy path where crate_type = ["dylib"] actually compiles and links.
Most helpful comment
In case someone else stumbles here, this and #3178 can be solved (or atleast worked around) by specifying "plugin = true" in the dylib's [lib] section (in this case in "inner"). I tried to check if it could be enabled automatically for dylibs, but an initial solution (forcing Target.for_host to be true for dylibs) broke cross compiling for dylibs. I have some progress done in https://github.com/jgke/cargo/tree/always-compile-dylibs, but I don't know how this should be actually solved.