Repository navigation
Serde with serde_derive fails to build in "alt" compiler on OS X #42967
Description
Steps to reproduce:
cargo new a
cd a
echo 'serde = {version = "1.0", features = ["serde_derive"]}' >> Cargo.toml
cargo buildAlternative steps to reproduce that will provides a suitable compiler:
# This branch is temporary,
# it will disappear once this issue is resolved and later be re-purposed
git clone https://github.com/servo/servo/ --branch rustup
cd servo
./mach cargo build -p serdeOn OS X, with LLVM assertions disabled (like in rustc builds added in #39754, which are the default in Servo’s mach), rustc 1.20.0-nightly (69c65d2 2017-06-28) fails with:
error: dlopen(/private/tmp/a/target/debug/deps/libserde_derive-73114808ba8f6d5d.dylib, 1): Library not loaded: @rpath/libstd-82587804d4836e27.dylib
Referenced from: /private/tmp/a/target/debug/deps/libserde_derive-73114808ba8f6d5d.dylib
Reason: image not found
--> /Users/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.8/src/lib.rs:261:1
|
261 | extern crate serde_derive;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
error: Could not compile `serde`.This problem does not occur with nightly-2017-06-29 from rustup, which has LLVM assertions enabled. (But perhaps that’s not the only difference between the two kinds of builds?)
Activity
SimonSapin commentedon Jun 29, 2017
What’s
RUST_CONFIGURE_ARGS="--enable-extended"?https://github.com/rust-lang/rust/pull/39754/files#diff-354f30a63fb0907d4ad57269548329e3R75
SimonSapin commentedon Jun 29, 2017
It’s also enabled in the "non-alt" build, so probably not relevant.
kennytm commentedon Jun 29, 2017
Have you tried building the project in the same disk partition where you've installed rustc, i.e. inside
/Users/...?SimonSapin commentedon Jun 29, 2017
Yes. With the second set of steps (and
-vadded), the error message looks like this:kennytm commentedon Jun 29, 2017
Does
DYLD_PRINT_RPATHS=1 cargo buildshow anything special?SimonSapin commentedon Jun 29, 2017
@kennytm not as far I can tell.
kennytm commentedon Jun 29, 2017
Okay... There are many other debugging options for dyld but I doubt if they are useful.
The problem is that
@rpath/libstd-82587804d4836e27.dylibis not found, meaning@rpath/is not expanded properly. I've checkedlibserde_derive-******.dylibdoes not have anLC_RPATHload command, meaning the@rpathis only supplied through the environment variableDYLD_LIBRARY_PATHset by Cargo.I don't think the alt-build's and normal build's Cargo has any difference though.
Verify if
rustc --print=sysrootis correct?SimonSapin commentedon Jun 29, 2017
./mach rustc --print=sysrootwith and withoutllvm-assertions = truein.servobuild:Both contain:
kennytm commentedon Jun 29, 2017
Both contains
libstd-82587804d4836e27.dylibdirectly insidelib/? (notlib/rustlib/<target>/lib/)SimonSapin commentedon Jun 29, 2017
Almost, the
-altone has a different hash:kennytm commentedon Jun 30, 2017
Huh, that's even stranger. The
@rpathshould be resolved correctly. But the alt- rustc linkedserde_deriveusing the libstd from the non-alt-build??SimonSapin commentedon Jun 30, 2017
Well it sounds unlikely to me that “from the other build” is really what’s going on, I’d bet on incorrect hashing. How is the hexadecimal part of
libstd-82587804d4836e27.dylibdetermined? What base values are being hashed?kennytm commentedon Jun 30, 2017
IIRC rustc will just search for all
libstd-*, it doesn't recompute the hash. Would it work if you move/Users/simon/tmp/servo-share/rust/69c65d29615c391c958ebf75dd65258ec23e175c/out of/Users/simon/tmp, and then do acargo clean+build?SimonSapin commentedon Jun 30, 2017
I first hit the issue before the "non-alt" build was downloaded.
kennytm commentedon Jun 30, 2017
I've tried to reproduce it myself and it seems
$PATHplays a role in finding whichlibstdis linked. I can make it link to the correctly hashedlibstdby:$PATHdoes not contain~/.cargo/bin, and includes«installed-path»/usr/local/binOverriding
$PATHwithout installing causes rustc not able to findlibcore.SimonSapin commentedon Jun 30, 2017
What is "it" and what does "installing" mean?
kennytm commentedon Jun 30, 2017
Run
./install.sh --destdir=«installed-path»after extracting the tarball (sorry was on mobile so did not check the exact instruction).SimonSapin commentedon Jun 30, 2017
What does this do besides copying the files?
Regardless, this is a regression, it only happens on OS X, and only with "alternate" builds…
Mark-Simulacrum commentedon Jun 30, 2017
It looks like the problem is presumably that
./.servo/rust/69c65d29615c391c958ebf75dd65258ec23e175c-alt/rustc-nightly-x86_64-apple-darwin/rustc/lib/libstd-5e0ec722ea8df7e6.dyliband./.servo/rust/69c65d29615c391c958ebf75dd65258ec23e175c-alt/rustc-nightly-x86_64-apple-darwin/rustc/lib/rustlib/x86_64-apple-darwin/lib/libstd-82587804d4836e27.dylibdon't have the same hash.One fairly clear problem is that Servo for some reason doesn't download rust-std from alt by-default AFAICT; having added some quick prints to the util script. That would lead to incompatibilities; this should be fixed.
Mark-Simulacrum commentedon Jun 30, 2017
I've filed servo/servo#17575 which should fix this.
SimonSapin commentedon Jun 30, 2017
Good catch! This fixes the problem, thank you.
Enable profiler on "alternate" builds
Rollup merge of rust-lang#43167 - SimonSapin:alt-profiler, r=alexcric…
Revert "Fetch "alt" rust std build when we do so for rustc"