search

rust-osdev / cargo-xbuild

Automatically cross-compiles the sysroot crates core, compiler_builtins, and alloc.
Apache License 2.0
258 stars 25 forks source link

Builds with same target specification are not equivalent #20

Closed berkus closed 5 years ago

berkus commented 5 years ago

The problem manifests when specifying the target in two different, but equivalent ways; which are then treated as non-equivalent by tooling:

Case 1

cargo xbuild --target=/path/to/vesper/targets/aarch64-vesper-metta.json

Case 2

set -x RUST_TARGET_PATH /path/to/vesper/targets/
cargo xbuild --target=aarch64-vesper-metta

The target points at the same file in the end, however, when building with the first command line and then switching to a second one, the tooling fails with:

   Compiling vesper v1.0.0 (/path/to/vesper)
error[E0461]: couldn't find crate `core` with expected target triple aarch64-vesper-metta
  |
  = note: the following crate versions were found:
          crate `core`, target triple aarch64-vesper-metta-16905780947483449836: /path/to/vesper/target/sysroot/lib/rustlib/aarch64-vesper-metta/lib/libcore-c3c957affa35580f.rlib

error: aborting due to previous error

After cargo clean the rebuild succeeds.

It seems that fingerprints are calculated entirely differently, while they should be the same.

phil-opp commented 5 years ago

These two ways are already different in rustc/cargo: With RUST_TARGET_PATH the target is treated as built-in target and no hash is appended. By passing a path to a json file, rustc understands that this a custom target and appends a hash (of the canonical file path) to differentiate between different custom targets with same file name (e.g. ~/foo/my-target.json and ~/bar/my-target.json).

berkus commented 5 years ago

I guess this has little chance to be fixed, given that cargo/rustc relies on this behavior.