-
Notifications
You must be signed in to change notification settings - Fork 13.3k
after 2016-02-24, rust-std-nightly-arm* tarballs ship with less .rlib
s and almost no .so
s
#32523
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
Labels
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Comments
Bah right, this is actually a problem I forgot to address with rustbuild in general. Right now it has two main phases of compilation, the standard library and the compiler. It assumes that the compiler is for hosts and the standard library is only for targets, but this isn't true as libtest is part of the target suite we distribute. This seems like it's straight up just a rustbuild bug. |
japaric
pushed a commit
to japaric-archived/rust-everywhere
that referenced
this issue
Mar 27, 2016
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Apr 1, 2016
The `rust-std` package that we produce is expected to have not only the standard library but also libtest for compiling unit tests. Unfortunately this does not currently happen due to the way rustbuild is structured. There are currently two main stages of compilation in rustbuild, one for the standard library and one for the compiler. This is primarily done to allow us to fill in the sysroot right after the standard library has finished compiling to continue compiling the rest of the crates. Consequently the entire compiler does not have to explicitly depend on the standard library, and this also should allow us to pull in crates.io dependencies into the build in the future because they'll just naturally build against the std we just produced. These phases, however, do not represent a cross-compiled build. Target-only builds also require libtest, and libtest is currently part of the all-encompassing "compiler build". There's unfortunately no way to learn about just libtest and its dependencies (in a great and robust fashion) so to ensure that we can copy the right artifacts over this commit introduces a new build step, libtest. The new libtest build step has documentation, dist, and link steps as std/rustc already do. The compiler now depends on libtest instead of libstd, and all compiler crates can now assume that test and its dependencies are implicitly part of the sysroot (hence explicit dependencies being removed). This makes the build a tad less parallel as in theory many rustc crates can be compiled in parallel with libtest, but this likely isn't where we really need parallelism either (all the time is still spent in the compiler). All in all this allows the `dist-std` step to depend on both libstd and libtest, so `rust-std` packages produced by rustbuild should start having both the standard library and libtest. Closes rust-lang#32523
bors
added a commit
that referenced
this issue
Apr 1, 2016
rustbuild: Fix dist for non-host targets The `rust-std` package that we produce is expected to have not only the standard library but also libtest for compiling unit tests. Unfortunately this does not currently happen due to the way rustbuild is structured. There are currently two main stages of compilation in rustbuild, one for the standard library and one for the compiler. This is primarily done to allow us to fill in the sysroot right after the standard library has finished compiling to continue compiling the rest of the crates. Consequently the entire compiler does not have to explicitly depend on the standard library, and this also should allow us to pull in crates.io dependencies into the build in the future because they'll just naturally build against the std we just produced. These phases, however, do not represent a cross-compiled build. Target-only builds also require libtest, and libtest is currently part of the all-encompassing "compiler build". There's unfortunately no way to learn about just libtest and its dependencies (in a great and robust fashion) so to ensure that we can copy the right artifacts over this commit introduces a new build step, libtest. The new libtest build step has documentation, dist, and link steps as std/rustc already do. The compiler now depends on libtest instead of libstd, and all compiler crates can now assume that test and its dependencies are implicitly part of the sysroot (hence explicit dependencies being removed). This makes the build a tad less parallel as in theory many rustc crates can be compiled in parallel with libtest, but this likely isn't where we really need parallelism either (all the time is still spent in the compiler). All in all this allows the `dist-std` step to depend on both libstd and libtest, so `rust-std` packages produced by rustbuild should start having both the standard library and libtest. Closes #32523
xmas7
added a commit
to xmas7/rust-phonebook
that referenced
this issue
Sep 6, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
STR
Most likely the cause is that this std component is now being produced using rustbuild.
I don't particularly mind the lack of
.so
s but thelibtest.rlib
is important to me because I use it to cross compile unit tests to ARM which then I run under QEMU. But now I'm gettingcan't find the crate for test
errors.cc @alexcrichton
The text was updated successfully, but these errors were encountered: