Cargo: Doc-tests and `dylib` dependency

Created on 29 Aug 2017  ยท  6Comments  ยท  Source: rust-lang/cargo

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.

C-bug Command-test

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.

All 6 comments

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.

Was this page helpful?
0 / 5 - 0 ratings