poor error messages when depending on a |crate-type = ["staticlib"]| crate #3169
Description
I have a library, gkrust-gtest, that depends on another library, gkrust. When gkrust's crate-type is set to ["staticlib"] in Cargo.toml, I get the following output:
Fresh mp4parse-gtest v0.1.0 (file:///home/froydnj/src/gecko-dev.git/dom/media/gtest)
Fresh byteorder v0.5.3
Fresh nsstring v0.1.0 (file:///home/froydnj/src/gecko-dev.git/xpcom/rust/nsstring)
Fresh mp4parse v0.5.1 (file:///home/froydnj/src/gecko-dev.git/media/libstagefright/binding/mp4parse)
Fresh nsstring-gtest v0.1.0 (file:///home/froydnj/src/gecko-dev.git/xpcom/rust/nsstring/gtest)
Fresh mp4parse_capi v0.5.1 (file:///home/froydnj/src/gecko-dev.git/media/libstagefright/binding/mp4parse_capi)
Fresh gkrust v0.1.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/rust)
Compiling gkrust-gtest v0.1.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/gtest/rust)
Running `/usr/local/bin/rustc /home/froydnj/src/gecko-dev.git/toolkit/library/gtest/rust/lib.rs --crate-name gkrust_gtest --crate-type staticlib -C opt-level=1 -C panic=abort -C codegen-units=1 -C debug-assertions=on -C metadata=c6d79253ac32483b --out-dir /opt/build/froydnj/build-rust-mc/toolkit/library/gtest/rust/./x86_64-unknown-linux-gnu/debug/deps --emit=dep-info,link --target x86_64-unknown-linux-gnu -L dependency=/opt/build/froydnj/build-rust-mc/toolkit/library/gtest/rust/./x86_64-unknown-linux-gnu/debug/deps --extern mp4parse_gtest=/opt/build/froydnj/build-rust-mc/toolkit/library/gtest/rust/./x86_64-unknown-linux-gnu/debug/deps/libmp4parse_gtest.rlib --extern nsstring_gtest=/opt/build/froydnj/build-rust-mc/toolkit/library/gtest/rust/./x86_64-unknown-linux-gnu/debug/deps/libnsstring_gtest.rlib -C debuginfo=1`
error[E0463]: can't find crate for `gkrust`
--> /home/froydnj/src/gecko-dev.git/toolkit/library/gtest/rust/lib.rs:5:1
|
5 | extern crate gkrust;
| ^^^^^^^^^^^^^^^^^^^^
This error is most puzzling, as gkrust's Cargo.toml is where one would expect, etc. If you look at the deps folder, you can even see a libgkrust.a file:
toolkit/library/gtest/rust/x86_64-unknown-linux-gnu/debug/deps:
total 8664
-rw-r--r-- 1 froydnj froydnj 274976 Oct 5 22:39 libbyteorder-3f87aa5c5a324af1.rlib
-rw-r--r-- 1 froydnj froydnj 5857872 Oct 6 17:46 libgkrust.a
-rw-r--r-- 1 froydnj froydnj 982010 Oct 5 22:39 libmp4parse_capi.rlib
-rw-r--r-- 1 froydnj froydnj 5968 Oct 5 22:39 libmp4parse_gtest.rlib
-rw-r--r-- 1 froydnj froydnj 1194406 Oct 5 22:39 libmp4parse.rlib
-rw-r--r-- 1 froydnj froydnj 118874 Oct 5 22:39 libnsstring_gtest.rlib
-rw-r--r-- 1 froydnj froydnj 369538 Oct 5 22:39 libnsstring.rlib
The error from rustc is misleading. Notice that the rustc invocation doesn't include an --extern for gkrust. The real problem here is that Cargo isn't telling the user upfront, "hey, you can't link to a staticlib library like that, you need to do something different."
Listing rlib as a crate-type solves the problem, but it would be most excellent if Cargo detected the configuration problem first, rather than leaving rustc to do a poor job of diagnosing the issue.