search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
96.2k stars 12.44k forks source link

Nightly cannot be installed today #55866

Closed nagisa closed 4 years ago

nagisa commented 5 years ago

x86_64-unknown-linux-gnu nightly (I believe 2018-11-11) will not install when running install.sh script. 

  install: installing component 'llvm-tools-preview'
  install: copying file /nix/store/95jw2r1mzzglhwhc02my02ipvvljl7hs-rust/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm
  cp: -r not specified; omitting directory '/build/rust-nightly-x86_64-unknown-linux-gnu/llvm-tools-preview/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm'
  chmod: cannot access '/nix/store/95jw2r1mzzglhwhc02my02ipvvljl7hs-rust/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm': No such file or directory
  install: error: file creation failed. see logs at '/nix/store/95jw2r1mzzglhwhc02my02ipvvljl7hs-rust/lib/rustlib/install.log'
hamedsh commented 5 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

Mark-Simulacrum commented 5 years ago

cc @alexcrichton @nrc

alexcrichton commented 5 years ago

This looks like it's likely specifically related to the llvm-tools-preview component, and doesn't empirically seem to affect all nightly installations.

hellow554 commented 5 years ago

Also godbolt is not able to use nightly atm https://rust.godbolt.org/z/rjZtBJ

grafik

lovesegfault commented 5 years ago

This has broken the Mozilla Nix overlay for all nightly releases past 2018-11-10.

bkchr commented 5 years ago

Any update why this is broken?

lovesegfault commented 5 years ago

Pinging @nrc and @alexcrichton again regarding this.

hellow554 commented 5 years ago

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"

19h commented 5 years ago

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.

19h commented 5 years ago

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

wiml commented 5 years ago

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).

lovesegfault commented 5 years ago

@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.

nrc commented 5 years ago

cc @tromey does this make sense? Do you have time to take a look please?

kennytm commented 5 years ago

5 PRs are merged between 2018-11-10 and 2018-11-11.

nikic commented 5 years ago

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 :(

nagisa commented 5 years ago

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
nagisa commented 5 years ago

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.

nagisa commented 5 years ago

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:

  1. Tarball(s)’ extraction;
  2. Something in between;
  3. Tarball generation.

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.

nagisa commented 5 years ago

This does not affect the just-uplifted beta tarballs.

nagisa commented 5 years ago

The issue has automagically fixed itself, without a clear reason why (no relevant tarball building code changes have taken place in the meantime).

Mark-Simulacrum commented 4 years ago

Hm seems like this has been fixed so I'm going to go ahead and close.