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.

Sign up for GitHub

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

Jump to bottom

Setting --libdir breaks rustc build #27254

Closed
saschmit opened this issue Jul 24, 2015 · 0 comments · Fixed by #31074
Closed

Setting --libdir breaks rustc build #27254

saschmit opened this issue Jul 24, 2015 · 0 comments · Fixed by #31074

Comments

@saschmit
Copy link

Fedora x86_64 builds install libraries to /usr/lib64 so that 32-bit and 64-bit libraries can coexist on the same system. However, with configure --prefix=/usr --libdir=/usr/lib64 && make, the build breaks:

...
rustc: x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore
rustc: x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc
/home/builder/rust/src/liblibc/lib.rs:81:38: 81:56 error: can't find crate for `core`
/home/builder/rust/src/liblibc/lib.rs:81 #[cfg(not(feature = "cargo-build"))] extern crate core;
                                                                              ^~~~~~~~~~~~~~~~~~
error: aborting due to previous error
/home/builder/rust/mk/target.mk:162: recipe for target 'x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.libc' failed
make: *** [x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.libc] Error 101

It appears that libraries are getting generated at stage0/lib but the build is (maybe?) looking for them at stage0/lib64. The results of find x86_64-unknown-linux-gnu/stage0:

x86_64-unknown-linux-gnu/stage0
x86_64-unknown-linux-gnu/stage0/bin
x86_64-unknown-linux-gnu/stage0/bin/rustc
x86_64-unknown-linux-gnu/stage0/lib64
x86_64-unknown-linux-gnu/stage0/lib64/rustlib
x86_64-unknown-linux-gnu/stage0/lib64/rustlib/x86_64-unknown-linux-gnu
x86_64-unknown-linux-gnu/stage0/lib64/rustlib/x86_64-unknown-linux-gnu/bin
x86_64-unknown-linux-gnu/stage0/lib64/rustlib/x86_64-unknown-linux-gnu/lib
x86_64-unknown-linux-gnu/stage0/test
x86_64-unknown-linux-gnu/stage0/lib
x86_64-unknown-linux-gnu/stage0/lib/rustlib
x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu
x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/bin
x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib
x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.libc.start_time
x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-e9599659.rlib
x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler-rt.a
x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmorestack.a
x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.core

I can only assume the same problem will probably propagate through later stages.

This is from doing a bootstrap build of the 1.1.0 tag (i.e., commit 35ceea3) in rust git, but I've also tried bootstrapping using commit 320bd6f and gotten the same results.

I've tried hunting down hard-coded "lib" and replacing it with $CFG_LIBDIR_RELATIVE. However, that did not resolve the problem, so perhaps something else is going on.

Possibly related: #11671, #22831, #16552

Output of ./x86_64-unknown-linux-gnu/stage0/bin/rustc --version --verbose:

rustc 1.1.0-dev (857ef6e27 2015-04-27) (built 2015-04-27)
binary: rustc
commit-hash: 857ef6e272e5634cb9f3e6ee50eb6bc2a2e71651
commit-date: 2015-04-27
build-date: 2015-04-27
host: x86_64-unknown-linux-gnu
release: 1.1.0-dev
@ghost ghost mentioned this issue Jan 21, 2016
Merged
bors added a commit that referenced this issue Jan 22, 2016
@bors
Auto merge of #31074 - gmbonnet:stage0-libdir, r=alexcrichton
cd1b845 
This fixes #27254.

On a 64-bit Linux machine, for example, `configure --libdir=/usr/local/lib64` was creating both `x86_64-unknown-linux-gnu/stage0/lib/rustlib` and `x86_64-unknown-linux-gnu/stage0/lib64/rustlib`. Crates from the stage0 snapshot, like `libcore`, are extracted to `x86_64-unknown-linux-gnu/stage0/lib/rustlib`, but the stage0 compiler was attempting to find them in `x86_64-unknown-linux-gnu/stage0/lib64/rustlib`, which has the highest priority on a 64-bit system.

The issue can be fixed by creating only `x86_64-unknown-linux-gnu/stage0/lib/rustlib`, since this is the only rustlib directory needed for stage0 anyways.
@alexcrichton alexcrichton mentioned this issue Mar 16, 2016
Closed
@sanmai-NL sanmai-NL mentioned this issue Apr 15, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

configure: Do not generate two stage0 rustlib dirs when --libdir is set
2 participants
@steveklabnik @saschmit