Skip to content

after 2016-02-24, rust-std-nightly-arm* tarballs ship with less .rlibs and almost no .sos #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

Closed
japaric opened this issue Mar 27, 2016 · 1 comment
Labels
T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@japaric
Copy link
Member

japaric commented Mar 27, 2016

STR

$ curl -sL 'https://static.rust-lang.org/dist/2016-03-23/rust-std-nightly-armv7-unknown-linux-gnueabihf.tar.gz' | tar --strip-components 1 -xz
$ tree rust-std-armv7-unknown-linux-gnueabihf/lib/rustlib/armv7-unknown-linux-gnueabihf/lib
├── liballoc-10e97cc6.rlib
├── liballoc_jemalloc-10e97cc6.rlib
├── liballoc_system-10e97cc6.rlib
├── libarena-10e97cc6.rlib
├── libarena-10e97cc6.so
├── libcollections-10e97cc6.rlib
├── libcompiler-rt.a
├── libcore-10e97cc6.rlib
├── libflate-10e97cc6.rlib
├── libflate-10e97cc6.so
├── libgetopts-10e97cc6.rlib
├── libgetopts-10e97cc6.so
├── libgraphviz-10e97cc6.rlib
├── libgraphviz-10e97cc6.so
├── liblibc-10e97cc6.rlib
├── liblog-10e97cc6.rlib
├── liblog-10e97cc6.so
├── librand-10e97cc6.rlib
├── librbml-10e97cc6.rlib
├── librbml-10e97cc6.so
├── librustc_bitflags-10e97cc6.rlib
├── librustc_unicode-10e97cc6.rlib
├── libserialize-10e97cc6.rlib
├── libserialize-10e97cc6.so
├── libstd-10e97cc6.rlib
├── libstd-10e97cc6.so
├── libterm-10e97cc6.rlib
├── libterm-10e97cc6.so
├── libtest-10e97cc6.rlib
└── libtest-10e97cc6.so
$ curl -sL 'https://static.rust-lang.org/dist/2016-03-24/rust-std-nightly-armv7-unknown-linux-gnueabihf.tar.gz' | tar --strip-components 1 -xz
$ tree rust-std-armv7-unknown-linux-gnueabihf/lib/rustlib/armv7-unknown-linux-gnueabihf/lib
├── liballoc-8250b9d58dbcb765.rlib
├── liballoc_jemalloc-09807bb22a185088.rlib
├── liballoc_system-4bf32b7cb9861654.rlib
├── libcollections-03ff6b8167d2df61.rlib
├── libcompiler-rt.a
├── libcore-28829d33c69225e4.rlib
├── liblibc-9de2ff21354cb608.rlib
├── librand-ff6d915f814fe089.rlib
├── librustc_unicode-b372888cd484ca87.rlib
├── libstd-1d20f6bd73ff8b5a.rlib
└── libstd-1d20f6bd73ff8b5a.so

Most likely the cause is that this std component is now being produced using rustbuild.

I don't particularly mind the lack of .sos but the libtest.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 getting can't find the crate for test errors.

cc @alexcrichton

@alexcrichton
Copy link
Member

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.

@alexcrichton alexcrichton added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Mar 27, 2016
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
Labels
T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

No branches or pull requests

2 participants