`crate-type = ["staticlib"]` prevents build metadata from being passed

[Twey]

It appears that marking a crate as crate-type = ["staticlib"] causes the dependency metadata generated by the package to be dropped on the floor.

[twey@uruz:/tmp/mwe]$ find . -type f | while read -r i; do echo $i; cat $i; echo ---; done
./bar/Cargo.toml
[package]
name = "bar"
version = "0.1.0"
authors = []

[dependencies]
foo = {path = "../foo"}
---
./bar/src/lib.rs
---
./bar/build.rs
fn main() {
    let _ = std::env::var("DEP_FOO_INCLUDE").unwrap();
}
---
./foo/Cargo.toml
[package]
name = "foo"
version = "0.1.0"
authors = []
links = "foo"

[lib]
crate-type = ["staticlib"]
---
./foo/src/lib.rs
---
./foo/build.rs
fn main() {
    println!("cargo:include=foo_include");
}
---

Attempting to build this gives:

[twey@uruz:/tmp/mwe]$ cargo --version
cargo 0.25.0-nightly (930f9d949 2017-12-05)
[twey@uruz:/tmp/mwe/bar]$ cargo build --verbose
   Compiling bar v0.1.0 (file:///tmp/mwe/bar)
   Compiling foo v0.1.0 (file:///tmp/mwe/foo)
     Running `rustc --crate-name build_script_build build.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=9d7440d88b76b1df -C extra-filename=-9d7440d88b76b1df --out-dir /tmp/mwe/bar/target/debug/build/bar-9d7440d88b76b1df -L dependency=/tmp/mwe/bar/target/debug/deps`
     Running `rustc --crate-name build_script_build /tmp/mwe/foo/build.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=1989f1c3f6a74e80 -C extra-filename=-1989f1c3f6a74e80 --out-dir /tmp/mwe/bar/target/debug/build/foo-1989f1c3f6a74e80 -L dependency=/tmp/mwe/bar/target/debug/deps`
     Running `/tmp/mwe/bar/target/debug/build/foo-1989f1c3f6a74e80/build-script-build`
     Running `rustc --crate-name foo /tmp/mwe/foo/src/lib.rs --crate-type staticlib --emit=dep-info,link -C debuginfo=2 -C metadata=a8d8421aee24b709 -C extra-filename=-a8d8421aee24b709 --out-dir /tmp/mwe/bar/target/debug/deps -L dependency=/tmp/mwe/bar/target/debug/deps`
     Running `/tmp/mwe/bar/target/debug/build/bar-9d7440d88b76b1df/build-script-build`
error: failed to run custom build command for `bar v0.1.0 (file:///tmp/mwe/bar)`
process didn't exit successfully: `/tmp/mwe/bar/target/debug/build/bar-9d7440d88b76b1df/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotPresent', /checkout/src/libcore/result.rs:916:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

warning: build failed, waiting for other jobs to finish...
error: build failed

But after commenting out the crate-type line this project builds fine.

A tarball of this MWE can be found here.

[Twey]

Actually, cdylib also has this behaviour; rlib, dylib, and proc-macro pass the environment through fine.

[alexcrichton]

I think this is expected behavior because in general you can't really do anything if you depend on a cdylib or a staticlib. Could you detail a bit more what the use case is for depending on a staticlib?

[Twey]

We have a Rust crate (foo) that builds a staticlib, and a dependent crate (bar) that builds some C code that links against that staticlib. I'd like for foo to be able to tell bar where its output ended up, since it also copies some header files there.

[alexcrichton]

Ok thanks for the extra info! This may be a problem that's best suited for an external build system perhaps though? Cargo in general isn't really intended to be optimized for building C code.

[Twey]

It's not a question of building C code so much as building Rust code that depends on C code. Obviously if it were a C program depending on a C dependency that would make sense, but in this case it's effectively a Rust program with a build dependency on some other Rust code. You can imagine that a staticlib crate could want to pass other information down the dependency chain, as we commonly do with -sys crates for example.

[Twey]

Our current hackaround for this is to build both an rlib and a staticlib, and depend on the rlib if we happen to be building from Cargo and the staticlib otherwise.

[alexcrichton]

I don't really understand the desired architecture here well enough to make any recommendations (or know if we should fix this bug in particular). If you have Rust code depending on Rust code that's best done through rlibs (not staticlibs) as staticlib/cdylib style projects come in when you have a C API.

[Twey]

It's just that in this case, due to implementation details, the dependency comes via a C API.
Either way, this seems like a surprising behaviour to me.

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using rust-lang/rust#6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[Twey]

Unstale! Still the case, still relevant. It's very confusing behaviour to silently drop the output of build.rs depending on the build type.

[dbcfd]

Similar experience, staticlib meant for a c application, attempting to pull into a rust application.

Would be nice to have a better error than can't find crate, something indicating there's no metadata because of crate type.