Closed nagisa closed 4 years ago
change file llvm-tools-preview/manifest.in to this (note:replace "file" with "dir"):
dir:lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm dir:lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-strip dir:lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata dir:lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objdump dir:lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objcopy dir:lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-readobj dir:lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-size
cc @alexcrichton @nrc
This looks like it's likely specifically related to the llvm-tools-preview
component, and doesn't empirically seem to affect all nightly installations.
Also godbolt is not able to use nightly atm https://rust.godbolt.org/z/rjZtBJ
This has broken the Mozilla Nix overlay for all nightly releases past 2018-11-10.
Any update why this is broken?
Pinging @nrc and @alexcrichton again regarding this.
I'm not sure if godbolts fault or related. It will now give an other error message.
error: couldn't load codegen backend "/opt/compiler-explorer/rust-nightly/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so": "librustc_codegen_ssa-2b046bccfab6fdd6.so: cannot open shared object file: No such file or directory"
I'm seeing this issue beginning November 12th in my automated Travis builds of Rust nightly: https://travis-ci.org/psychonautwiki/docker-rust-nightly/builds/461544482.
First failure was November 11th, although that built happened at 12:47am, so I guess this regression was introduced 11/11.
Simply using the rustup.rs installer is a workaround for us:
curl -sO https://static.rust-lang.org/dist/rust-$RUST_VERSION-x86_64-unknown-linux-gnu.tar.gz && \
tar -xzf rust-$RUST_VERSION-x86_64-unknown-linux-gnu.tar.gz && \
./rust-$RUST_VERSION-x86_64-unknown-linux-gnu/install.sh --without=rust-docs
vs
curl https://sh.rustup.rs -sSf | sh -s -- --default-toolchain nightly -y && \
The former yields the error discussed here, the latter builds just fine [1].
[1] https://travis-ci.org/psychonautwiki/docker-rust-nightly/builds/461770017
The problem, I suppose, is that all the things in llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin
that I'd expect to be executables are actually empty directories. From current nightly:
$ ls -lR llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin
llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin:
total 28
drwxr-xr-x 2 wiml wiml 4096 Dec 1 06:53 llvm-nm
drwxr-xr-x 2 wiml wiml 4096 Dec 1 06:53 llvm-objcopy
drwxr-xr-x 2 wiml wiml 4096 Dec 1 06:53 llvm-objdump
drwxr-xr-x 2 wiml wiml 4096 Dec 1 06:53 llvm-profdata
drwxr-xr-x 2 wiml wiml 4096 Dec 1 06:53 llvm-readobj
drwxr-xr-x 2 wiml wiml 4096 Dec 1 06:53 llvm-size
drwxr-xr-x 2 wiml wiml 4096 Dec 1 06:53 llvm-strip
I spot checked a few past versions; in the 2018-10-11 nightly, for example, those are actual executables instead of empty directories. So perhaps this is a bug in the build system that was introduced sometime after then.
The workaround then is to pass --without=llvm-tools-preview
to install.sh
(or to pass an explicit --components=…
list which is I assume what rustup et al do).
@alexcrichton @nrc Please take a look at this. This has pretty much nuked our usual workflow at Standard Cognition. I've took a stab at this after a chat with @nagisa the other night, but I couldn't understand why or how the llvm executables end up as directories.
cc @tromey does this make sense? Do you have time to take a look please?
At least in the archive at https://static.rust-lang.org/dist/llvm-tools-nightly-x86_64-unknown-linux-gnu.tar.gz
the tools seem to be present as usual. Installing of llvm-tools-preview
works fine for me locally :(
For a locally built dist
the directory contains proper files.
tar tvf build/dist/rust-1.32.0-dev-x86_64-unknown-linux-gnu.tar.xz | grep llvm
drwxr-xr-x 1000/100 0 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview
drwxr-xr-x 1000/100 0 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib
drwxr-xr-x 1000/100 0 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib
drwxr-xr-x 1000/100 0 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu
drwxr-xr-x 1000/100 0 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin
-rwxr-xr-x 1000/100 422672 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata
-rwxr-xr-x 1000/100 341864 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-size
-rwxr-xr-x 1000/100 1544616 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-readobj
-rw-r--r-- 1000/100 46498 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/rust-docs/share/doc/rust/html/unstable-book/language-features/link-llvm-intrinsics.html
-rw-r--r-- 1000/100 22202 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/rust-docs/share/doc/rust/html/src/core/up/stdsimd/coresimd/simd_llvm.rs.html
-rwxr-xr-x 1000/100 406088 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm
-rw-r--r-- 1000/100 404 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/manifest.in
-rwxr-xr-x 1000/100 77490152 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/rustc/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
-rwxr-xr-x 1000/100 671808 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-strip
-rwxr-xr-x 1000/100 909720 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objdump
-rwxr-xr-x 1000/100 671808 2018-12-06 00:43 rust-1.32.0-dev-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objcopy
I’ve built a full dist on a newer (clean) checkout and settings closer to what the CI uses. It still resulted in a tarballs with proper files, as one would expect. I’m not willing to put docker on my system, so some other way to investigate this will be necessary.
I suspect that the outcome is not exactly caused by the operation of build system, but rather some specific of the CI and its environment.
The tool responsible for creating the final combined tarball is the fabricate combiner. It takes, as an input, a number of tarballs (one of them being the llvm-tools
, which is correct as pointed out by @nikic above), unpacks them into a temporary work directory and then makes a tarball out of the work directory again with all files in it.
This does narrow the potential failure points quite significantly. In summary the things that can fail are:
It is not strictly necessary for tarball combination process to extract all the files and the combine them back. The .tar
files can be combined directly without extracting them into filesystem, removing a whole class of potential failure scenarios, while also being faster due to not hitting the filesystem.
One way or the other this is where it would be ideal to have some sanity checking for the manifest files.
This does not affect the just-uplifted beta tarballs.
The issue has automagically fixed itself, without a clear reason why (no relevant tarball building code changes have taken place in the meantime).
Hm seems like this has been fixed so I'm going to go ahead and close.
x86_64-unknown-linux-gnu nightly (I believe 2018-11-11) will not install when running
install.sh
script.