rustc --target argument hard-coded in generated libraries

[gz]

Using --target feature in rust will hard-code the provided path in the library. Linking these libraries against applications will fail if they use same target.json but with a different (e.g., relative) path.

I tried this code:
lib.rs:

#![feature(no_std)]
#![no_std]

main.rs

#![feature(lang_items, start, no_std)]
#![no_std]
extern crate lib;

#[lang="phantom_fn"]
trait PhantomFn<A: ?Sized, R: ?Sized = ()> {}
#[lang="sized"]
trait Sized: PhantomFn<Self> {}
#[lang="copy"]
trait Copy: PhantomFn<Self> {}
#[lang="sync"]
trait Sync: PhantomFn<Self> {}

#[start]
fn start() {
}
#[lang = "stack_exhausted"] extern fn stack_exhausted() {}
#[lang = "eh_personality"] extern fn eh_personality() {}
#[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} }

Now, I compile the lib.rs as a library

rustc --crate-type=lib --emit=link -O --cfg arch__x86_64 --target=target.json --crate-name lib lib.rs

...and main.rs as an application using liblib.rlib (I'm in folder play):

Works:
rustc --emit=obj -L dependency=./ -O --cfg arch__x86_64 --target=target.json --extern lib=./liblib.rlib -o main.o main.rs
Does not work:
rustc --emit=obj -L dependency=./ -O --cfg arch__x86_64 --target=../play/target.json --extern lib=./liblib.rlib -o main.o main.rs

Instead, this happened:

rustc --emit=obj -L dependency=./ -O --cfg arch__x86_64 --target=../play/target.json --extern lib=./liblib.rlib -o main.o main.rs

main.rs:4:1: 4:18 error: couldn't find crate `lib` with expected target triple ../play/target.json
main.rs:4 extern crate lib;
          ^~~~~~~~~~~~~~~~~
main.rs:4:18: 4:18 note: crate `lib`, path #1, triple target.json: /home/gz/workspace/play/liblib.rlib
error: aborting due to previous error

Meta

rustc --version --verbose:

rustc 1.0.0-nightly (c89de2c56 2015-03-28) (built 2015-03-29)
binary: rustc
commit-hash: c89de2c56baeb61e7cc434924dcc8bedd32b26b8
commit-date: 2015-03-28
build-date: 2015-03-29
host: x86_64-unknown-linux-gnu
release: 1.0.0-nightly

[eddyb]

Should a hash of the (parsed and normalized) target spec be used, instead?

[gz]

That would solve the problem I think. Maybe instead of hashing include the whole (normalized) target spec so the compiler can give a better hint on a conflict?

[gz]

A problem is that strings inside the target file may be equivalent. For example: "features": "-3dnow,-3dnowa" vs. "features": "-3dnowa,-3dnow"

[JustAPerson]

Ideally, the actual contents of the json file would be included, but storing a hash would at least allow the same target file to be used from different working directories.

[JustAPerson]

So, running into this again. Given that the existing solution (compare exact paths given to --target is rather non-robust), perhaps we can loosen the requirement to just comparing filenames?

[jethrogb]

You can get around this by using the RUST_TARGET_PATH environment variable and only using the basename.

Note that this also affects cross-installation and finding of libstd: if you build libstd with an absolute path, there is no way to install it such that rustc can find std for your target.

[Mark-Simulacrum]

Few more things from the issue I closed as a duplicate of this one:

• If relative paths are used different relative paths pointing to the same file will be seen as different targets (this is the problem here)
• Relative paths pointing to different files may result in a match (not really noted here, but a problem)
• If absolute paths are used the target specifications may not be moved around the filesystem without doing a full rebuild (a problem, and the cause of this issue)
• The path to the target specification is leaked all over the place, and target-related errors become verbose

[steveklabnik]

Triage: don't believe anything has changed here

[bjorn3]

Fixed by #98225 by storing the contents of the target spec instead.