Opened 5 years ago
Closed 5 years ago
#11521 closed enhancement (fixed)
Upgrade rustc for firefox-65.0
| Reported by: | Owned by: | Bruce Dubbs | |
|---|---|---|---|
| Priority: | normal | Milestone: | 8.4 |
| Component: | BOOK | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Firefox-65.0 is expected to be released on 20th January, after a "soft freeze" on 21st January. It will need at least version 1.30 of rust. As in past practice, we should prefer the latest version.
The 1.30 series was first released on 6th December (point release on about 20th December) which suggests that 1.32.0 will be released around the 23rd January because the minor versions seem to be on a 7-week cycle.
We can probably use 1.31.1, but never trust release schedules! (there might be late changes somewhere which require a later version).
Change History (43)
comment:1 by , 5 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 5 years ago
comment:3 by , 5 years ago
Indeed it was, and it showed up in your daily version check.
On my ryzen (which is the most up-to-date system), this is giving me a lot more grief than 1.31.0. Specifically, a lot of segmentation faults in the tests (in lto tests), and then current firefox-beta (65.0b11) fails to build in gkrust with a segfault.
Retrying, just in case, was no different. Tried *forcing* thinlto in llvm (that might be the default now, but it looks as if the build might be slightly smaller) which reduced 23 failures to 22.
Meanwhile, on an old phenom running mostly BLFS-8.3 it seemed fine (only 4 test failures, three of which are for thumb (ARM) compiler variants) and successfully built firefox-64.0.2.
Short current status: severely broken on *my* ryzen, on other machines the test results might be a lot better than previous versions (e.g. it seems to be ok in gdb tests, and to skip those if gdb is not present). Currently trying with system llvm upgraded to 7.0.1 on the ryzen, that doesn't seem to make any odds (still the segfaults in the tests), but will retry firefox later to be sure.
Meanwhile, earlier in the week I completed testing 1.31.0 with all its users (firefox-release as well as beta, thunderbird, librsvg, and running the gdb testsuite (ambivalent, but didn't seem to be worse than with 1.29).
One, or perhaps two, other things to try - I see that gentoo and Arch do not appear to have problems although neither have beta (source). I also don't know if the segmentation fault in building firefox on this machine also applies to 64.0.2.
I'm seriously thinking about giving up on this and learning to love binary distros. If I can't get anywhere, will reinstall 1.31.0 and see if the segfaults are because some RAM has decided to fail.
follow-up: 5 comment:4 by , 5 years ago
Ken,
I've got a system with a AMD Phenom X2 521 in it that's not being used for anything at the moment (it's been sitting dormant for a couple months now). I don't currently have LFS/BLFS on it, but I could put it on it if the results would assist you at all. I just don't know what I'd use it for afterwards - just run stable BLFS on it?
Either way, if you want - I can get it going to get results for you. Here are links to it's specs (although I've upgraded the RAM):
https://support.hp.com/us-en/document/c02863024
I'll need help finding firmware for it though. OTOH, I suppose I could use it for testing the AMD/ATI drivers at release time...
comment:5 by , 5 years ago
Replying to renodr:
Ken,
I've got a system with a AMD Phenom X2 521 in it that's not being used for anything at the moment (it's been sitting dormant for a couple months now). I don't currently have LFS/BLFS on it, but I could put it on it if the results would assist you at all. I just don't know what I'd use it for afterwards - just run stable BLFS on it?
Either way, if you want - I can get it going to get results for you. Here are links to it's specs (although I've upgraded the RAM):
https://support.hp.com/us-en/document/c02863024
I'll need help finding firmware for it though. OTOH, I suppose I could use it for testing the AMD/ATI drivers at release time...
Thanks, but no thanks. My own phenom is a II x4 965 (no idea how they compare) and from time to time it loses its lunch and segfaults, probably because the motherboard is not supplying adequate voltage for the memory. But that machine (after dropping the caches, because of its general segfaults) built 64.0.2 without problems. The problem seems to be specific to ryzens, or even (given the lack of other reports on the previous firefox bug) specific to _my_ ryzen. Currently seeing if it can build 64.0.2 with 1.32.0, but not optimistic.
My impression is that most people building on ryzens are using binary versions of rust, so if there is a problem it will take some time to become apparent. Meanwhile, the build farms at mozilla and at distros are probably mostly intel or very old (FX) AMD.
The key underlying problem, in my view, is that ryzen dropped a few opcodes, e.g. using binaries from a Fam15h Kaveri (before that started to die) failed to build.
comment:6 by , 5 years ago
I am hopeful that the problem is caused by using system llvm. There is an issue for rust where Arch's system llvm is blamed.
So, I tried building with the shipped llvm, and also for target ARM (to try to get clean test results by not failing the thumb tests). No reported segmentation faults (in practice, I still had a couple, plus 5 traps - the original ryzen problem), one test failure reported:
[run-make] run-make-fulldeps/sysroot-crates-are-unstable
which I have seen before and is the fourth failure on the other system.
Unfortunately, cannot build firefox:
0:05.98 checking rustc version... 1.32.0 0:06.03 checking cargo version... 1.32.0 0:06.35 DEBUG: <truncated - see config.log for full output> [...] 0:06.35 DEBUG: | error[E0514]: found crate `std` compiled by an incompatible version of rustc 0:06.35 DEBUG: | | 0:06.35 DEBUG: | = help: please recompile that crate using this compiler (rustc 1.32.0) 0:06.35 DEBUG: | = note: the following crate versions were found: 0:06.35 DEBUG: | crate `std` compiled by rustc 1.29.2: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-9f1d9aae8b99d108.rlib 0:06.35 DEBUG: | crate `std` compiled by rustc 1.31.1: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-57b3410c37ed439b.rlib 0:06.35 DEBUG: | crate `std` compiled by rustc 1.31.1: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-57b3410c37ed439b.so 0:06.35 DEBUG: | crate `std` compiled by rustc 1.29.2: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-160f1a26cff4fc58.rlib
And from firefox-build-dir/config.log:
INFO: checking cargo version...
DEBUG: Executing: `/usr/bin/cargo --version --verbose`
INFO: 1.32.0
DEBUG: Executing: `/usr/bin/rustc --print target-list`
DEBUG: Creating `/tmp/conftestxYkoWQ.rs` with content:
DEBUG: | pub extern fn hello() { println!("Hello world"); }
DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib --target=x86_64-unknown-linux-gnu -o /tmp/conftesthJIO24.rlib /tmp/conftestxYkoWQ.rs`
DEBUG: The command returned non-zero exit status 1.
DEBUG: Its error output was:
DEBUG: | error[E0464]: multiple matching crates for `std`
Google finds E0514 where people altered their code to fix test failures and had to recompile stage0. For E0464, no matches for the std crate.
Looks as if the target list is ok (all known target triplets), so the 'hello world' test within firefox's attempt to understand the installed rust is the problem. Possibly the static lib crate type.
Not sure where I'm going now, I think I might have broken the system (in particular, blowing away /usr/lib/rustlib will probably prevent me using the runnimg firefox if I have to reboot).
comment:7 by , 5 years ago
System *is* broken. I tried recompiling librsvg because that is the lightest user of rust. Similar errors for crates core and std.
The odd thing is that my logs show 1.32.0 completed its installation. Clearly something in my "use shipped llvm" build is incorrect.
IOn the end, I blew away /usr/lib/rustlib as well as /usr/bin/cargo* /usr/bin/clippy* /usr/bin/rls /usr/bin/rust* and /usr/share/doc/rustc* : but I still need to think about what is wrong with the latest build (and drop ARM).
Meanwhile, I've reinstalled 1.31.1. For future experiments with 1.32.0 I'll go back to installing in /opt (as well as getting it working, I want to look at the number of codegen units - with thinlto there is a compromise between rust's build time and space.
For reference, the issue with system LLVM on Arch is https://github.com/rust-lang/rust/issues/57762
comment:8 by , 5 years ago
Not looking good with 1.32.0. I had hoped to use thin-lto to save time and space. That turns out to need LLVM's lld linker (which is a separate download like cfe/clang). But after building that, it seems that it will only use *static* system libraries.
Gave up on that, trying a regular X86 build with shipped LLVM but it fails to load the stage1 codegen lib librustc_codegen_llvm-llvm.so with the message
LLVM-8svn.so: cannot open shared object file: No such file or directory
follow-up: 19 comment:9 by , 5 years ago
Any idea why rust wants a development version of LLVM? That seems sort of fishy to me.
Why don't we just use 1.31.1 and hold off on 1.32.0?
comment:10 by , 5 years ago
Just another data point. I built ructc-1.32.0 on my development system (12 core Haswell, 16G RAM). It seemed to almost finish and then:
error: failed to run custom build command for `miri v0.1.0 (/mnt/tmp/rustc/rustc-1.32.0-src/src/tools/miri)`
process didn't exit successfully: `/mnt/tmp/rustc/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2-tools/release/build/miri-7bdefdbab42072df/build-script-build` (exit code: 101)
--- stdout
cargo:rustc-env=PROFILE=release
cargo:rerun-if-changed=build.rs
cargo:rustc-env=VERGEN_BUILD_TIMESTAMP=2019-01-21T07:58:35.074019866+00:00
cargo:rustc-env=VERGEN_SHA=
cargo:rustc-env=VERGEN_BUILD_DATE=2019-01-21
cargo:rustc-env=VERGEN_SEMVER_LIGHTWEIGHT=0.1.0
cargo:rustc-env=VERGEN_SHA_SHORT=
cargo:rustc-env=VERGEN_SEMVER=0.1.0
cargo:rustc-env=VERGEN_TARGET_TRIPLE=x86_64-unknown-linux-gnu
cargo:rustc-env=VERGEN_COMMIT_DATE=
--- stderr
thread 'main' panicked at 'Unable to generate vergen keys!: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
warning: build failed, waiting for other jobs to finish...
error: build failed
command did not execute successfully: "/mnt/tmp/rustc/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "12" "--release" "--manifest-path" "/mnt/tmp/rustc/rustc-1.32.0-src/src/tools/miri/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
Build completed successfully in 0:21:44
This seems to match the caveat in the book.
I do have the following:
./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ./build/x86_64-unknown-linux-gnu/stage2/bin/rustc ./build/x86_64-unknown-linux-gnu/stage0/bin/rustc
I was able to run the stage2 version with
$ export LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage2/lib $ ./build/x86_64-unknown-linux-gnu/stage2/bin/rustc --version rustc 1.32.0
A ran the build manually with the instructions in the book so I do not have a log or timing. The directory size after build is 3.6G. I'm stopping now, and I have not run any tests yet. I have not run the install either. I'll try those tomorrow.
comment:11 by , 5 years ago
I did find this: https://github.com/rust-lang/rust/issues/56576
They closed the issue, but it does not seem to be fixed.
comment:13 by , 5 years ago
miri built OK with the patch. Build completed in about 20 SBU with 4 cores. 3.6 GB in source tree. +300 MB in user home.
follow-up: 21 comment:14 by , 5 years ago
I've run the tests (using instructions in the book). 15795 tests were run and 22 failed...
comment:15 by , 5 years ago
I've run a DESTDIR install (book instructions). With tests and install the size of the build tree is 7.5 GB, the size of the "install" dir is 716 MB. I do not have accurate timings for the last two operations, sorry.
So, seems to work on intel. Remains to find what to do with Ryzen...
comment:16 by , 5 years ago
Both cbindgen and librsvg could be compiled with the above build. I did not have a previous version of rust on this VM, so it might be that I only have the "good" crates.
follow-up: 25 comment:17 by , 5 years ago
When I did my test build last night, I did not adjust my ~/.cargo directory, Right now I have
[ ~ ]$ du -sh .cargo 747M .cargo
So it appears that the build procedure can handle old cargo files.
follow-up: 22 comment:18 by , 5 years ago
Tried to compile firefox-65.0, from firefox-65.0b12.source.tar.xz.
Using book instructions, with harfbuzz/graphite2 patch. The patch does not apply cleanly and I applied it manually.
After ~23 mn (with 4 cores), I get:
22:17.78 process didn't exit successfully: `/usr/bin/rustc --crate-name gkrust toolkit/library/rust/lib.rs --color never --crate-type staticlib --emit=dep-inf o,link -C opt-level=2 -C panic=abort -C codegen-units=1 -C lto --cfg 'feature="b indgen"' --cfg 'feature="cubeb-remoting"' --cfg 'feature="cubeb_pulse_rust"' --c fg 'feature="gecko_profiler"' --cfg 'feature="gkrust-shared"' --cfg 'feature="mo z_memory"' --cfg 'feature="quantum_render"' --cfg 'feature="servo"' -C metadata= c80ab26d4d3f38e1 -C extra-filename=-c80ab26d4d3f38e1 --out-dir /sources/firefox- 65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps --target x86_64-unk nown-linux-gnu -C linker=/sources/firefox-65.0/build/cargo-linker -L dependency=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps -L dependency=/sources/firefox-65.0/firefox-build-dir/release/deps --extern gkrust_shared=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps/libgkrust_shared-a27c3e3102207894.rlib --extern mozilla_central_workspace_hack=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps/libmozilla_central_workspace_hack-cb43fdc5b1f7b177.rlib -C opt-level=2 -C debuginfo=2 -L native=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/build/lmdb-sys-2deb7105a462014f/out` (signal: 11, SIGSEGV: invalid memory reference) 22:17.78 make[4]: *** [/sources/firefox-65.0/config/rules.mk:1052: force-cargo-library-build] Error 101
Well, SIGSEGV: invalid memory reference can come from the fact I use a VM...
comment:19 by , 5 years ago
Replying to renodr:
Any idea why rust wants a development version of LLVM? That seems sort of fishy to me.
Why don't we just use 1.31.1 and hold off on 1.32.0?
No idea why they require a development version, except that clearly they do. Note that on *some* machines 1.32.0 works fine, and for those the test results are much cleaner.
follow-up: 23 comment:20 by , 5 years ago
Morning folks.
rustc-1.32.0 on an i5-6600k:
Compiling vergen v3.0.3
Compiling miri v0.1.0 (/sources/rustc-1.32.0-src/src/tools/miri)
error: failed to run custom build command for `miri v0.1.0 (/sources/rustc-1.32.0-src/src/tools/miri)`
process didn't exit successfully: `/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2-tools/release/build/miri-7bdefdbab42072df/build-script-build` (exit code: 101)
--- stdout
cargo:rustc-env=PROFILE=release
cargo:rerun-if-changed=build.rs
cargo:rustc-env=VERGEN_BUILD_TIMESTAMP=2019-01-21T14:07:31.816889152+00:00
cargo:rustc-env=VERGEN_SEMVER_LIGHTWEIGHT=0.1.0
cargo:rustc-env=VERGEN_SHA=
cargo:rustc-env=VERGEN_COMMIT_DATE=
cargo:rustc-env=VERGEN_SEMVER=0.1.0
cargo:rustc-env=VERGEN_TARGET_TRIPLE=x86_64-unknown-linux-gnu
cargo:rustc-env=VERGEN_SHA_SHORT=
cargo:rustc-env=VERGEN_BUILD_DATE=2019-01-21
--- stderr
thread 'main' panicked at 'Unable to generate vergen keys!: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
command did not execute successfully: "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--manifest-path" "/sources/rustc-1.32.0-src/src/tools/miri/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
Build completed successfully in 0:30:10
If I wasn't busy working on the i686 box, I'd run it over there just for laughs. I'm having issues with it and Firefox/Thunderbird, so I'm going to just run a different web browser and email client. For some odd reason, rust won't link in swap space.
follow-up: 24 comment:21 by , 5 years ago
Replying to pierre.labastie:
I've run the tests (using instructions in the book). 15795 tests were run and 22 failed...
For 1.32.0 with only X86 enabled, you should get 4 failures (three for tests which require thumb (ARM) compilers, one for a cargo test). Having 22 failures matches my segfaults.
comment:22 by , 5 years ago
Replying to pierre.labastie:
Tried to compile firefox-65.0, from firefox-65.0b12.source.tar.xz.
Using book instructions, with harfbuzz/graphite2 patch. The patch does not apply cleanly and I applied it manually.
Version at http://www.linuxfromscratch.org/~ken/dev-patches/ hopefully applies cleanly.
After ~23 mn (with 4 cores), I get:
22:17.78 process didn't exit successfully: `/usr/bin/rustc --crate-name gkrust toolkit/library/rust/lib.rs --color never --crate-type staticlib --emit=dep-inf o,link -C opt-level=2 -C panic=abort -C codegen-units=1 -C lto --cfg 'feature="b indgen"' --cfg 'feature="cubeb-remoting"' --cfg 'feature="cubeb_pulse_rust"' --c fg 'feature="gecko_profiler"' --cfg 'feature="gkrust-shared"' --cfg 'feature="mo z_memory"' --cfg 'feature="quantum_render"' --cfg 'feature="servo"' -C metadata= c80ab26d4d3f38e1 -C extra-filename=-c80ab26d4d3f38e1 --out-dir /sources/firefox- 65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps --target x86_64-unk nown-linux-gnu -C linker=/sources/firefox-65.0/build/cargo-linker -L dependency=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps -L dependency=/sources/firefox-65.0/firefox-build-dir/release/deps --extern gkrust_shared=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps/libgkrust_shared-a27c3e3102207894.rlib --extern mozilla_central_workspace_hack=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps/libmozilla_central_workspace_hack-cb43fdc5b1f7b177.rlib -C opt-level=2 -C debuginfo=2 -L native=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/build/lmdb-sys-2deb7105a462014f/out` (signal: 11, SIGSEGV: invalid memory reference) 22:17.78 make[4]: *** [/sources/firefox-65.0/config/rules.mk:1052: force-cargo-library-build] Error 101Well, SIGSEGV: invalid memory reference can come from the fact I use a VM...
Yeah, gkrust is where the problem shows up.
comment:23 by , 5 years ago
Replying to renodr:
Morning folks.
rustc-1.32.0 on an i5-6600k:
Compiling vergen v3.0.3 Compiling miri v0.1.0 (/sources/rustc-1.32.0-src/src/tools/miri)
[...]
Build completed successfully in 0:30:10
Code 101 is not, in itself, fatal. The rust build system is nasty (builds which are marked as unsuccessful return a good status, allowing the tests, and then the install code, to each run for a time), but if it thinks it was successful then maybe it completed.
My expectation is that most problems will be on AMD (a comment on -book in reply to this ticket about a phenom having problems).
follow-up: 26 comment:24 by , 5 years ago
Replying to ken@…:
Replying to pierre.labastie:
I've run the tests (using instructions in the book). 15795 tests were run and 22 failed...
For 1.32.0 with only X86 enabled, you should get 4 failures (three for tests which require thumb (ARM) compilers, one for a cargo test). Having 22 failures matches my segfaults.
Actually, I had only run the statistics as explained in the book. I see now that some tests have failed on signal 11 (SIGSEGV). So the SIGSEGV in firefox is not unexpected...
comment:25 by , 5 years ago
Replying to bdubbs:
When I did my test build last night, I did not adjust my ~/.cargo directory, Right now I have
[ ~ ]$ du -sh .cargo 747M .cargo
So it appears that the build procedure can handle old cargo files.
They just build up - if the old versions are not used, they are merely taking space. 'The rust way' seems to be to use specific versions in each crate, so that three different versions can be used when building rust itself. If none are present, the required ones get downloaded.
comment:26 by , 5 years ago
Replying to pierre.labastie:
Replying to ken@…:
Actually, I had only run the statistics as explained in the book. I see now that some tests have failed on signal 11 (SIGSEGV). So the SIGSEGV in firefox is not unexpected...
Thanks, this is why a development version of LLVM is needed (or perhaps a patched version).
I might take another attempt at trying to build with the shipped LLVM tomorrow, but for the moment I think that 1.31.0 is the way to go.
comment:27 by , 5 years ago
PROGRESS ;-)
I've used the shipped llvm, got only 3 test failures, successfully compiled latest librsvg [ that is now my goto "does it seem to work" test ]. Still need to test-build beta and current stable firefoxes, cbindgen and thunderbird, and do other tests / measurements. The big difference is that I've put it in /opt/new. I've also disabled the docs (man pages seem to be present).
The build and DESTDIR install took 34 SBU, tests took only 15 SBU (for 1.31.1 with system llvm the figures were 28 SBU and 24 SBU). Space is MUCH smaller because of omitting the docs (5.7GB including the DESTDIR which adds 476MB when installed, i.e. 6.1GB total, tests add 2GB.
config.toml:
# see config.toml.example for more possible options [llvm] # use ninja ninja = true # by default, rust will build for a myriad of architectures targets = "X86" # When building llvm, WebAssembly and RISCV experimental # targets are the default. omit those experimental-targets = "" [build] # do not build and install the docs docs = false # install cargo as well as rust extended = true [install] prefix = "/opt/new" # keep a docdir for people who build the docs docdir = "share/doc/rustc-1.32.0" [rust] channel = "stable" rpath = false # BLFS does not install the FileCheck executable from llvm, # so disable codegen tests codegen-tests = false backtrace-on-ice = true
Logs (build, test, with summary added at end, install) at http://www.linuxfromscratch.org/~ken/logs/ (for the moment, I'll delete them at some point) - they probably show that I was building in /scratch/ken/crap - that is just a place for throwaway builds as a user, it is not a comment on what I am building.
comment:28 by , 5 years ago
Release notes at https://github.com/rust-lang/rust/blob/master/RELEASES.md
Note that both the earlier 1.31.0 and the current 1.32.0 are described as the '2018 edition'.
comment:29 by , 5 years ago
Successfully test-built the books's current versions of firefox, thunderbird, librsvg, cbindgen. Build firefox-65beta12. Ran the gdb tests (I have not kept earlier results, but the rust items looked similar or perhaps better).
Installed "for real" in /usr. Looking good, I'm now running firefox-65.0 (candidate 1).
follow-up: 31 comment:30 by , 5 years ago
Hey Ken, do you want me to look into that Phenom thing, and update the ticket with results from my machine? That will tell us whether or not we're looking at a fluke on gab's end or if there's a problem with Athlon/Phenom systems. It'll probably be 24-36 hours, depending on overall speed of my Phenom.
comment:31 by , 5 years ago
Replying to renodr:
Hey Ken, do you want me to look into that Phenom thing, and update the ticket with results from my machine? That will tell us whether or not we're looking at a fluke on gab's end or if there's a problem with Athlon/Phenom systems. It'll probably be 24-36 hours, depending on overall speed of my Phenom.
That is overtaken by events: upstream rust has now established that LLVM-7.0.1 is NOT good enough (errors on various crates).
However, I'm currently swearing and cursing - on my phenom where I had updated to 1.32.0 with system LLVM and things appeared to be ok, I "updated" to 1.32.0 with shipped LLVM. I'm back to rust only finding crates compiled by old versions (in this case 1.25.0 and 1.29.0). That seems to now be a feature of compiling 1.32.0 with system LLVM and then replacing it with a version using the shipped LLVM.
On my haswell which previously was running 1.29.2 the upgrade was fine, so this only seems to happen if upgrading from the same version with system LLVM.
follow-up: 33 comment:32 by , 5 years ago
On my Skylake with *shipped* LLVM, I'm having some serious issues with the tests... they abort!
- "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--rustdoc-path" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc" "--src-base" "/sources/rustc-1.32.0-src/src/test/run-make-fulldeps" "--build-base" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-make-fulldeps" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-make" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--nodejs" "/usr/bin/node" "--host-rustcflags" "-Crpath -O -Zunstable-options -Lnative=/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Zunstable-options -Lnative=/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python" "--lldb-python" "/usr/bin/python" "--gdb" "/usr/bin/gdb" "--verbose" "--quiet" "--llvm-version" "8.0.0svn\n" "--cc" "cc" "--cxx" "c++" "--cflags" "-ffunction-sections -fdata-sections -fPIC -m64" "--llvm-components" "aggressiveinstcombine all all-targets analysis asmparser asmprinter binaryformat bitreader bitwriter codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfomsf debuginfopdb demangle dlltooldriver engine executionengine fuzzmutate globalisel gtest gtest_main instcombine instrumentation interpreter ipo irreader libdriver lineeditor linker lto mc mcdisassembler mcjit mcparser mirparser native nativecodegen objcarcopts object objectyaml option optremarks orcjit passes profiledata runtimedyld scalaropts selectiondag support symbolize tablegen target testingsupport transformutils vectorize windowsmanifest x86 x86asmparser x86asmprinter x86codegen x86desc x86disassembler x86info x86utils xray" "--llvm-cxxflags" "-I/sources/rustc-1.32.0-src/src/llvm/include -I/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/llvm/build/include -ffunction-sections -fdata-sections -fPIC -m64 -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -fno-exceptions -fno-rtti -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS" "--ar" "ar" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" ""
Traceback (most recent call last):
File "./x.py", line 20, in <module>
bootstrap.main()
File "/sources/rustc-1.32.0-src/src/bootstrap/bootstrap.py", line 853, in main
bootstrap(help_triggered)
File "/sources/rustc-1.32.0-src/src/bootstrap/bootstrap.py", line 839, in bootstrap
run(args, env=env, verbose=build.verbose)
File "/sources/rustc-1.32.0-src/src/bootstrap/bootstrap.py", line 151, in run
raise RuntimeError(err)
RuntimeError: failed to run: /sources/rustc-1.32.0-src/build/bootstrap/debug/bootstrap test --verbose --no-fail-fast
This is what I have now, although the tests aborted:
renodr [ /sources/rustc-1.32.0-src ]$ grep '^test result:' rustc-testlog | awk
'{ sum += $6 } END { print sum }'
4
renodr [ /sources/rustc-1.32.0-src ]$ grep 'running .* tests' rustc-testlog | awk '{ sum += $2 } END { print sum }'
15795
This is a big improvement over *system* LLVM though:
renodr [ /sources/rustc-1.32.0-src.sysllvm ]$ grep 'running .* tests' rustc-testlog | awk '{ sum += $2 } END { print sum }'
15795
renodr [ /sources/rustc-1.32.0-src.sysllvm ]$ grep '^test result:' rustc-testlog | awk '{ sum += $6 } END { print sum }'
20
follow-up: 35 comment:33 by , 5 years ago
Replying to renodr:
On my Skylake with *shipped* LLVM, I'm having some serious issues with the tests... they abort!
Getting a traceback is normal (one or more tests failed). 4 failures is probably ok. If you look for FAIL in the log, I will guess that the last one is sysroot-crates-are-unstable in run-make ?
This is a big improvement over *system* LLVM though:
I assume you discarded that log. If not, or in your systemd journal, I assume there are many segfaults (two, and a number of traps for invalid opcodes, are normal).
comment:34 by , 5 years ago
There are a lot less segfaults for the *shipped* LLVM, but there are still several:
Wed 2019-01-23 20:18:27 CST 21007 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:18:48 CST 31981 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/abort-on-c-abi/a Wed 2019-01-23 20:19:20 CST 3685 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/backtrace/a Wed 2019-01-23 20:19:20 CST 3631 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/backtrace/a Wed 2019-01-23 20:19:24 CST 10423 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/default-alloc-error-hook/a Wed 2019-01-23 20:19:58 CST 18673 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/invalid_const_promotion/a Wed 2019-01-23 20:20:20 CST 24468 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/issues/issue-24313/a Wed 2019-01-23 20:20:22 CST 10263 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:20:33 CST 13786 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:21:18 CST 8997 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/out-of-stack/a Wed 2019-01-23 20:21:22 CST 9039 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/out-of-stack/a Wed 2019-01-23 20:21:24 CST 10749 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/abort/a Wed 2019-01-23 20:21:27 CST 10780 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/abort-link-to-unwinding-crates/a Wed 2019-01-23 20:21:54 CST 20991 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/running-with-no-runtime/a Wed 2019-01-23 20:21:56 CST 21272 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/segfault-no-out-of-stack/a Wed 2019-01-23 20:22:02 CST 22793 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/signal-exit-status/a Wed 2019-01-23 20:22:03 CST 24721 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/simd/simd-target-feature-mixup/a Wed 2019-01-23 20:22:13 CST 917 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:22:13 CST 25388 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes/a Wed 2019-01-23 20:22:39 CST 974 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:23:24 CST 10796 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:23:35 CST 10737 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:23:37 CST 22319 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:23:56 CST 25171 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:25:12 CST 13804 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:25:34 CST 16712 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:40:17 CST 26664 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:40:25 CST 26989 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:40:38 CST 28960 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:40:49 CST 30324 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:40:49 CST 30458 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:40:50 CST 30465 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:40:51 CST 30321 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:40:52 CST 31085 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:44:36 CST 4798 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:44:39 CST 4850 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:44:43 CST 5350 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:44:49 CST 4787 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:44:51 CST 4788 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:44:54 CST 4753 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:44:56 CST 4906 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:44:57 CST 4789 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:45:05 CST 4916 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:45:15 CST 6794 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:45:15 CST 4851 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:50:47 CST 8485 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:50:48 CST 8296 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:50:51 CST 8444 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:50:52 CST 8363 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:50:55 CST 8437 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:50:57 CST 8476 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:50:59 CST 8334 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:50:59 CST 8534 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:51:45 CST 10793 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:52:42 CST 10730 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:52:43 CST 10765 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:52:47 CST 10883 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:52:49 CST 10767 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:52:53 CST 10831 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:52:59 CST 10893 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:53:02 CST 10766 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:53:06 CST 12810 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:57:20 CST 13054 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:57:22 CST 13119 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:57:22 CST 13193 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:57:22 CST 13241 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:57:22 CST 13232 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:57:23 CST 13290 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:57:23 CST 13198 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 20:57:23 CST 13083 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc Wed 2019-01-23 23:20:43 CST 23460 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/abort-on-c-abi/a Wed 2019-01-23 23:21:13 CST 27121 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/backtrace/a Wed 2019-01-23 23:21:14 CST 27164 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/backtrace/a Wed 2019-01-23 23:21:16 CST 1844 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/default-alloc-error-hook/a Wed 2019-01-23 23:21:41 CST 10054 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/invalid_const_promotion/a Wed 2019-01-23 23:21:56 CST 15939 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/issues/issue-24313/a Wed 2019-01-23 23:22:43 CST 2472 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/out-of-stack/a Wed 2019-01-23 23:22:45 CST 2831 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/out-of-stack/a Wed 2019-01-23 23:22:47 CST 5663 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/abort/a Wed 2019-01-23 23:22:47 CST 5653 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/abort-link-to-unwinding-crates/a Wed 2019-01-23 23:22:50 CST 8358 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/lto-abort/a Wed 2019-01-23 23:23:04 CST 14766 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/running-with-no-runtime/a Wed 2019-01-23 23:23:05 CST 14788 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/segfault-no-out-of-stack/a Wed 2019-01-23 23:23:07 CST 15792 1000 1000 11 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/signal-exit-status/a Wed 2019-01-23 23:23:09 CST 16211 1000 1000 4 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/simd/simd-target-feature-mixup/a Wed 2019-01-23 23:23:11 CST 16878 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes/a Wed 2019-01-23 23:23:14 CST 17753 1000 1000 6 present /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes-lto/a
With *system* LLVM, I have close to 275 coredumps.
As for the difference in time, I forgot to use Bruce's sed and it failed while I was asleep.
As for invalid opcodes:
[987171.293783] traps: a[23460] trap invalid opcode ip:557dfccb3b3b sp:7fff1a7ad0a0 error:0 in a[557dfccb2000+3000] [987181.162671] traps: a[27121] trap invalid opcode ip:7fbd9c4a6abf sp:7ffea4ea5920 error:0 in libstd-be3f5b84c0422bf0.so[7fbd9c49c000+71000] [987181.405544] traps: a[27164] trap invalid opcode ip:7fc20d3deabf sp:7ffce6318600 error:0 in libstd-be3f5b84c0422bf0.so[7fc20d3d4000+71000] [987230.071842] traps: a[10054] trap invalid opcode ip:557cfdfad5d1 sp:7ffef27d8d90 error:0 in a[557cfdfac000+2000] [987313.464168] a[14788]: segfault at 0 ip 00005591671569b8 sp 00007ffe13d70600 error 6 in a[559167155000+2000] [987313.464174] Code: 00 00 48 8b b4 24 00 01 00 00 48 85 f6 74 1e 48 8b bc 24 f8 00 00 00 ba 01 00 00 00 ff 15 88 35 00 00 eb 09 ff 15 d8 35 00 00 <c6> 00 01 48 8b 84 24 50 01 00 00 48 c1 e0 03 48 8d 1c 40 31 ed 4c [987316.148033] a[15792]: segfault at 1 ip 000055dff4cfc57e sp 00007ffe19aa3b90 error 6 in a[55dff4cfb000+2000] [987316.148039] Code: 48 85 c0 74 16 48 c1 e0 03 48 8d 34 40 ba 08 00 00 00 4c 89 ff ff 15 e9 29 00 00 48 81 c4 a8 01 00 00 5b 41 5c 41 5e 41 5f c3 <48> c7 04 25 01 00 00 00 00 00 00 00 eb 90 48 8d 3d 0d 27 00 00 31 [987317.945057] traps: a[16211] trap invalid opcode ip:5635add9cb0f sp:7ffe802b88d0 error:0 in a[5635add9b000+4000]
follow-up: 36 comment:35 by , 5 years ago
Replying to ken@…:
Replying to renodr:
On my Skylake with *shipped* LLVM, I'm having some serious issues with the tests... they abort!
Getting a traceback is normal (one or more tests failed). 4 failures is probably ok. If you look for FAIL in the log, I will guess that the last one is sysroot-crates-are-unstable in run-make ?
This is a big improvement over *system* LLVM though:
I assume you discarded that log. If not, or in your systemd journal, I assume there are many segfaults (two, and a number of traps for invalid opcodes, are normal).
My totals (with only 3 failed tests are 15687 passed, 108 ignored (if gdb is present), or 15605 and 190 if gdb is not available. The totals are about 3 greater than the claimed number of tests.
For miri I am now using
export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" && ./x.py build --exclude src/tools/miri
You added your traces and segfaults while I was writing that, can you look at the latest log and search for segfault / sigsegv / signal 11 to find out if any were reported in the output.
comment:36 by , 5 years ago
Replying to ken@…:
Replying to ken@…:
Replying to renodr:
On my Skylake with *shipped* LLVM, I'm having some serious issues with the tests... they abort!
Getting a traceback is normal (one or more tests failed). 4 failures is probably ok. If you look for FAIL in the log, I will guess that the last one is sysroot-crates-are-unstable in run-make ?
This is a big improvement over *system* LLVM though:
I assume you discarded that log. If not, or in your systemd journal, I assume there are many segfaults (two, and a number of traps for invalid opcodes, are normal).
My totals (with only 3 failed tests are 15687 passed, 108 ignored (if gdb is present), or 15605 and 190 if gdb is not available. The totals are about 3 greater than the claimed number of tests.
With GDB installed, I get 15795 total tests, 4 "failures", and 108 ignored.
For miri I am now using
export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" && ./x.py build --exclude src/tools/miriYou added your traces and segfaults while I was writing that, can you look at the latest log and search for segfault / sigsegv / signal 11 to find out if any were reported in the output.
It doesn't seem that any are reported, at least via a simple grep. I can upload my rustc-testlog to my webspace if that'll help at all.
As an example of one of my coredumps (seems to be a SIGABRT):
PID: 17753 (a)
UID: 1000 (renodr)
GID: 1000 (renodr)
Signal: 6 (ABRT)
Timestamp: Wed 2019-01-23 23:23:14 CST (11h ago)
Command Line: /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes-lto/a child-thread
Executable: /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes-lto/a
Control Group: /system.slice/sshd.service
Unit: sshd.service
Slice: system.slice
Boot ID: b14abce378314253b307b60837c5de6f
Machine ID: 7777b247b5d14d1d980532e847b5461b
Hostname: POOH
Storage: /var/lib/systemd/coredump/core.a.1000.b14abce378314253b307b60837c5de6f.17753.1548307394000000.xz
Message: Process 17753 (a) of user 1000 dumped core.
comment:37 by , 5 years ago
First set of changes in r21033 - updated now to help reduce the confusion when people test it. Details of failures might need tweaking if more come to light.
I've also put down a marker in the changelog that it will be moving to /opt, but that the instructions for using it should be in a form where an existing install in /usr can be used.
That will be a time to document the problems a bit more, and maybe to advise using a different prefix if rebuilding with major changes in config.toml (e.g. shipped llvm vs system llvm).
comment:38 by , 5 years ago
Just a progress report. I tried to change the value of prefix in config.toml to /opt/rust or /opt/rustc-1.32.0, but it won't work. I've developed a workaround.
After DESTDIR=${PWD}/install ./x.py install:
mkdir -p install/opt/rustc-1.32.0 mv install/usr/* install/opt/rustc-1.32.0 rmdir install/usr
and then continue with
chown -R root:root install cp -a install/* /
And finish with
ln -sfnv rustc-1.32.0 /opt/rustc
For ld.so.conf, add '/opt/rustc/lib' and run ldconfig.
Add a boot script that does 'pathprepend /opt/rustc/bin'
Seems to work. I'll create a new branch and change the book there for review.
comment:39 by , 5 years ago
This is the modified rust page for review:
http://www.linuxfromscratch.org/~bdubbs/blfs-book/general/rust.html
comment:40 by , 5 years ago
Using input from Ken, I've simplified the proposed rust page:
http://www.linuxfromscratch.org/~bdubbs/blfs-book/general/rust.html
This is the same location as the previous comment.
comment:41 by , 5 years ago
I've updated the book with (optional) instructions to build rustc in /opt. There may still be some changes needed so I'm leaving this ticket open for Ken to review what is now in the book, make any changes needed, and then finally close this ticket.
We have been trying to get this working properly for quite a while. I do not know if we want to update llvm-7.0.1 with Arch's patch and try rebuilding rust with system llvm. Maybe that should wait until the next rust version.
comment:42 by , 5 years ago
| Owner: | changed from to |
|---|---|
| Status: | assigned → new |
I think we should make the wording for /opt stronger, whilst still allowing people to use /usr, and spell out why. Also, use ln -svfn for the symlink instead of first removing /opt/rustc (I was not aware of that option until Bruce pointed it out to me, I think it has educational benefit). And explain that people should use a different prefix if rebuilding.
Although I said I wasn't going to mention the problem re reinstalling the same version after changing from system llvm to shipped llvm, I changed my mind now we are using /opt, and spelled it out so that future readers can see why we changed.
Committed at r21044, passing to Bruce to alter if he thinks I've overdone it, or to close.
comment:43 by , 5 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This is close enough. If changes are needed, reopen or create a new ticket.
According to that paragon of correct information, slashdot, rustc-1.32.0 was released last Thursday.
$ du -sh rustc-1.32.0-src.tar.gz 152M rustc-1.32.0-src.tar.gz $ md5sum rustc-1.32.0-src.tar.gz 366f049777e00d0d6f15d25895485efb rustc-1.32.0-src.tar.gz