Open
Description
Note that the following can only happen when calling rustc
directly instead of going through cargo
as cargo
uses an rlib filename scheme that works and AFAIU doesn't allow overriding that anyway.
I tried this code:
a/lib.rs
:
pub fn foo() -> i32 {
123
}
b/lib.rs
:
pub fn bar() -> i32 {
some_a::foo() * 2
}
c/main.rs
:
fn main() {
//use b::bar;
println!("{}", b::bar());
}
When compiling this as follows it will fail on the third rustc
invocation.
mkdir -p builddir
rm -f builddir/liba.rlib
rm -f builddir/libb.rlib
rm -f builddir/c
rustc --crate-type rlib --edition=2021 --crate-name some_a --emit link -o builddir/liba.rlib a/lib.rs
rustc --crate-type rlib --edition=2021 --crate-name b --emit link -o builddir/libb.rlib --extern some_a=builddir/liba.rlib -L builddir b/lib.rs
rustc --crate-type bin --edition=2021 --crate-name c --emit link -o builddir/c --extern b=builddir/libb.rlib -L builddir c/main.rs
This gives the following error with latest stable (1.68.2) and also 660c966
error[E0463]: can't find crate for `some_a` which `b` depends on
--> c/main.rs:3:20
|
3 | println!("{}", b::bar());
| ^ can't find crate
error: aborting due to previous error
Note that the crate name of a is some_a
while the rlib file is called liba.rlib
. If changing either the crate name to a
or the filename to libsome_a.rlib
it works.
More confusingly, when using 660c966 and uncommenting the use b::foo
line, it gives a different error
error[E0519]: the current crate is indistinguishable from one of its dependencies: it has the same crate-name `b` and was compiled with the same `-C metadata` arguments. This will result in symbol conflicts between the two.
--> c/main.rs:2:9
|
2 | use b::bar;
| ^
error[E0519]: the current crate is indistinguishable from one of its dependencies: it has the same crate-name `b` and was compiled with the same `-C metadata` arguments. This will result in symbol conflicts between the two.
--> c/main.rs:3:20
|
3 | println!("{}", b::bar());
| ^
error: aborting due to 2 previous errors
I would expect
- both cases to give the same error message
- either using an "invalid" rlib name should fail directly (i.e. first
rustc
invocation above), or compilation of the above testcase should work fine