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

Use a stage-dependent shared library directory for testing. #26405

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
4 participants
@eddyb
Copy link
Member

eddyb commented Jun 18, 2015

Unbreaks check-stage0-CRATE where CRATE may be one of coretest, std, syntax, rustc_driver, etc.

Use a stage-dependent shared library directory for testing.
Unbreaks `check-stage0-CRATE` where `CRATE` may be one of `coretest`, `std`, `syntax`, `rustc_driver`, etc.
@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jun 18, 2015

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jun 18, 2015

Have you checked to make sure this actually works? Testing locally we still pass -Z no-landing-pads to stage0 compiles which causes stage0 stdtest to fail.

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jun 18, 2015

This also appears to have been added in c60d9ad, and although I don't remember the precise reason why this commit does indeed break cross-host builds. I configured a host of 32/64 bit locally and got this during compilation:

$ make -j10
cfg: version 1.2.0-dev (f45181276 2015-06-18)
cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples i686-unknown-linux-gnu x86_64-unknown-linux-gnu
cfg: target triples i686-unknown-linux-gnu x86_64-unknown-linux-gnu
cfg: non-build host triples i686-unknown-linux-gnu
cfg: non-build target triples i686-unknown-linux-gnu
cfg: host for i686-unknown-linux-gnu is i386
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: os for i686-unknown-linux-gnu is unknown-linux-gnu
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: good valgrind for i686-unknown-linux-gnu is 1
cfg: good valgrind for x86_64-unknown-linux-gnu is 1
cfg: using CC=ccache gcc (CFG_CC)
cfg: enabling valgrind run-pass tests (CFG_ENABLE_VALGRIND_RPASS)
cfg: valgrind-rpass command set to "/usr/bin/valgrind" --error-exitcode=100 --fair-sched=try --quiet --soname-synonyms=somalloc=NONE --suppressions=/home/alex/code/rust2/src/etc/x86.supp  --tool=memcheck --leak-check=full
cfg: no xelatex found, disabling LaTeX docs
cfg: no pandoc found, omitting PDF and EPUB docs
rustc: i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/libcore
i686-unknown-linux-gnu/stage0/bin/rustc: error while loading shared libraries: librustc_driver-d8ace771.so: cannot open shared object file: No such file or directory
make: *** [i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.core] Error 127
make: INTERNAL: Exiting with 11 jobserver tokens available; should be 10!
@eddyb

This comment has been minimized.

Copy link
Member Author

eddyb commented Jun 18, 2015

Oh, right, check-stage0-stdtest didn't finish, but it did run (and ended hanging up after a failure of sync::mutex::tests::test_mutex_arc_access_in_unwind).
All the other tests I've tried compiled and ran successfully.

The cross-host build issue is one I had not anticipated, and I will have to look into it, but I still don't believe hardcoding stage1 in is a good idea - I have no idea how it even runs at stage2, other than the fact that there might be no dynamic dependencies.

@eddyb

This comment has been minimized.

Copy link
Member Author

eddyb commented Jun 25, 2015

I'll close this since check-stage0-rustc_driver just started working for no apparent reason after a rebase.

@eddyb eddyb closed this Jun 25, 2015

@bluss

This comment has been minimized.

Copy link
Contributor

bluss commented Jul 4, 2015

This makefile tweak allows collectionstest to run in stage0, do you think it can be fixed & merged?

@eddyb

This comment has been minimized.

Copy link
Member Author

eddyb commented Jul 4, 2015

@bluss I think I was mistaken, it broke again. Maybe the removal of stage1 libs during reconfigure made it work for a little bit.
I'm not sure what the correct solution is, our makefiles are a bit of a jungle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.