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

stage 0 libtests are broken #55864

Closed
RalfJung opened this issue Nov 11, 2018 · 8 comments
Closed

stage 0 libtests are broken #55864

RalfJung opened this issue Nov 11, 2018 · 8 comments
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@RalfJung
Copy link
Member

The command ./x.py test --stage 0 src/libstd --no-doc used to be a good way to test libstd without having to build a full compiler. However, it is currently broken:

Testing std stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
   Compiling rand_core v0.2.1                                                                                                                                                                                      
   Compiling libc v0.2.43                                                                                                                                                                                          
   Compiling rand v0.5.5                                                                                                                                                                                           
   Compiling std v0.0.0 (/home/r/src/rust/rustc.2/src/libstd)                                                                                                                                                      
error: the #[global_allocator] in this crate conflicts with global allocator in: std                                                                                                                               
                                                                                                                                                                                                                   
error: aborting due to previous error                                                                                                                                                                              
                                                                                                                                                                                                                   
error: Could not compile `std`.                                                                                                                                                                                    

To learn more, run the command again with --verbose.


command did not execute successfully: "/home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "8" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/home/r/src/rust/rustc.2/src/libstd/Cargo.toml" "--lib" "--bins" "--examples" "--tests" "--benches" "-p" "std" "--" "--quiet"
expected success, got: exit code: 101

Cc @alexcrichton

@RalfJung
Copy link
Member Author

Now it seems like stage 1 doctests are broken as well...

   Doc-tests std
error: couldn't load codegen backend "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so": "librustc_codegen_ssa-93008c931eecc4cb.so: cannot open shared object file: No such file or directory"

Cc @eddyb @bjorn3 might be related to the codegen refactoring?

@eddyb
Copy link
Member

eddyb commented Nov 26, 2018

@RalfJung I don't know why that would be a problem, but maybe rustbuild isn't copying the right files.

@bjorn3
Copy link
Member

bjorn3 commented Nov 27, 2018

#56196 may have the same root cause.

@eddyb
Copy link
Member

eddyb commented Dec 7, 2018

Can we try moving rustc_codegen_ssa to a dependency of rustc_driver?
Maybe it just doesn't work otherwise.
(Maybe librustc_driver.so makes all of its .so dependencies available to dynamic loading?)

@bjorn3
Copy link
Member

bjorn3 commented Dec 8, 2018

Can we try moving rustc_codegen_ssa to a dependency of rustc_driver?

I did originally, but @Mark-Simulacrum wanted to avoid rebuilding the driver when cg_ssa changed.

Quoting part of #56048 (comment):

We can maybe move the specific dependency edge to src/rustc to avoid rebuilding driver (or shift rustbuild around to use some other "fake" root crate).

@eddyb
Copy link
Member

eddyb commented Dec 8, 2018

@bjorn3 Yeah but I think it's just broken if it's not a dependency of rustc_driver.

@bjorn3
Copy link
Member

bjorn3 commented Dec 8, 2018

I will make a PR to do it in a few minutes.

bjorn3 added a commit to bjorn3/rust that referenced this issue Dec 8, 2018
@estebank estebank added A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jan 19, 2019
@petrochenkov
Copy link
Contributor

Transient stage0 problem should not be tracked by GitHub issues generally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants