Cross-host builds are broken (and nightlies) #32568
Comments
|
Sucks. That change was necessary to make c-dynamic-dylib pass on my test server (host x86-64, target x86-unknown-linux). Are we just stuck backing out the whole thing and having |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 29, 2016
The change in b20e748 had the unintended consequence of breaking cross-host builds as we apparently relied on the incorrect definition of this variable in the makefiles. That change, however, was required to get tests passing so we couldn't just revert it. This commit fixes the underlying bug by leaving the "more correct" definition of `LD_LIBRARY_PATH_ENV_TARGETDIR` (also fixing it with a hardcoded reference to `CFG_BUILD`) and updating the `RPATH_VAR` definition below. Turned out we already had special-casing logic for passing `--cfg stage1` during the well-we-print-this-as-stage0 build of a cross-host. That logic was just updated to pull from a different variable as opposed to relying on the definition of that variable to accommodate this. Closes rust-lang#32568
bors
added a commit
that referenced
this issue
Mar 30, 2016
mk: Fix cross-host builds The change in b20e748 had the unintended consequence of breaking cross-host builds as we apparently relied on the incorrect definition of this variable in the makefiles. That change, however, was required to get tests passing so we couldn't just revert it. This commit fixes the underlying bug by leaving the "more correct" definition of `LD_LIBRARY_PATH_ENV_TARGETDIR` (also fixing it with a hardcoded reference to `CFG_BUILD`) and updating the `RPATH_VAR` definition below. Turned out we already had special-casing logic for passing `--cfg stage1` during the well-we-print-this-as-stage0 build of a cross-host. That logic was just updated to pull from a different variable as opposed to relying on the definition of that variable to accommodate this. Closes #32568
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The bots are failing due to opaque rpath issues. I believe this was caused by b20e748 in #32252 (cc @durka)
I'm tired and gonna go to bed, but I've got a build running which I'll hopefully be able to diagnose tomorrow morning. Just wanted to file this to make sure we know nightlies aren't working.
The text was updated successfully, but these errors were encountered: