Cargo: Using [target.*.dependencies] results in error about crate-type

[ferrouswheel]

When using [target.'cfg(unix)'.dependencies] in my Cargo.toml, and then using cargo run|test|build I get a somewhat obtuse error:

error: failed to learn about crate-type `dylib` early on

If I place the dependency I require directly in [dependencies] everything builds fine on linux (but this breaks other platforms).

• rustc 1.14.0 (e8a012324 2016-12-16)
• cargo 0.15.0-nightly (298a012 2016-12-20)

$ rustc --print cfg
target_os="linux"
target_family="unix"
target_arch="x86_64"
target_endian="little"
target_pointer_width="64"
target_env="gnu"
unix
debug_assertions

Project this occurs with is here: https://github.com/ferrouswheel/rust-sparkline

I currently have the [target.'cfg(unix)'.dependencies] bit commented out to get successful builds on travis. You should be able to reproduce by uncommenting that section and removing lodepng from [dependencies].

There is an example failure here: https://travis-ci.org/ferrouswheel/rust-sparkline/jobs/189709678 (Note: I would expect that particular build to fail with a compile error, but it doesn't even get to compiling).

[alexcrichton]

I attempted to fix this in #3525 but unfortunately that won't work.

The problem here is that lodepng depends on a precise version of c_vec, and that historical version of c_vec was listed with:

[lib]
crate-type = ["dylib", "rlib"]

When Cargo is discovering the list of crate types to learn about it doesn't travel this dependency edge because it's platform-specific and Cargo doesn't know about platform-specific dependencies yet. That means that Cargo ends up not learning about the dylib crate type, but then later on we do indeed need it when compiling c_vec.

Unfortunately I'm not sure of the best way of how to solve this...

[kornelski]

FWIW I've relaxed version of c_vec in lodepng.

but I've ran into the same problem myself with another crate where I need a static library on Windows only. The default (rlib?) doesn't seem to re-export symbols from C (compiled with the gcc build dep).

[philn]

I'm also interested in having this issue fixed.

[alexcrichton]

@philn @ferrouswheel I think this may be fixed on master versions of cargo, mind trying the nightly channel?

[philn]

Yes indeed it looks like this is fixed with cargo 0.23.0-nightly (8118b02ac 2017-09-14) at least. Thanks!

[alexcrichton]

Ok! In that case I'm going to close