Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-reproducible builds when depending on local crates #98185

Open
shkoo opened this issue Jun 17, 2022 · 4 comments
Open

Non-reproducible builds when depending on local crates #98185

shkoo opened this issue Jun 17, 2022 · 4 comments
Labels
A-reproducibility Area: Reproducible / Deterministic builds C-bug Category: This is a bug.

Comments

@shkoo
Copy link
Contributor

shkoo commented Jun 17, 2022

It looks like meta fingerprints are not particularly stable when it comes to depending on local crates (i.e. with a dependency specifying a "path", a "[patch.crates-io]" section or a "__CARGO_TESTS_ONLY_SRC_ROOT" environment variable); different absolute pathnames seem to produce different build fingerprints. This makes it difficult to reproduce builds when running as a different user or on a different operating system or distribution.

--remap-path-prefix doesn't seem to help at all here.

To reproduce this problem:


for i in a b
do
    mkdir $i
    (   
        cd $i
        TOPDIR=`pwd`
        cargo new --lib repro
        cat > repro/src/lib.rs <<EOF 
pub fn foo() -> usize { 
    ext_crate::add(1, 2) 
} 
EOF 
        cp -r ../ext_crate ext_crate
        cat > repro/Cargo.toml <<EOF 
[package] 
name = "repro" 
version = "0.1.0" 
edition = "2021" 
 
[dependencies] 
ext_crate = { version = "0.1.0", path="../ext_crate" } 
 
EOF 
        (   
            cd repro
            RUSTFLAGS="--remap-path-prefix=${TOPDIR}=/stablepath" cargo build -vv --release --target-dir=build
        )
    )
done
diff -ur [ab]/repro/build

My expected behavior here would be that those two builds would be identical and reproducible.

These are the versions I am using:

$ cargo --version --verbose
cargo 1.63.0-nightly (4d92f07f3 2022-06-09)
release: 1.63.0-nightly
commit-hash: 4d92f07f34ba7fb7d7f207564942508f46c225d3
commit-date: 2022-06-09
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1n)
os: Ubuntu 20.04 (focal) [64-bit]
$ rustc --version --verbose
rustc 1.63.0-nightly (546c826f0 2022-06-12)
binary: rustc
commit-hash: 546c826f0ccaab36e897860205281f490db274e6
commit-date: 2022-06-12
host: x86_64-unknown-linux-gnu
release: 1.63.0-nightly
LLVM version: 14.0.5
@shkoo shkoo added the C-bug Category: This is a bug. label Jun 17, 2022
@eggyal
Copy link
Contributor

eggyal commented Jun 17, 2022

@rustbot label +A-reproducibility

@rustbot rustbot added the A-reproducibility Area: Reproducible / Deterministic builds label Jun 17, 2022
@ijackson
Copy link
Contributor

I think this bug may be responsible for the nonreproducibility of Hippotat in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028254
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/hippotat.html

@rwmacleod
Copy link

This bug may also be the same problem that is seen in the Yocto builds:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14875

@ijackson
Copy link
Contributor

ijackson commented Feb 7, 2023

This might be related to rust-lang/cargo#5505

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-reproducibility Area: Reproducible / Deterministic builds C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

5 participants