rustc-1.19.0

[ken@…]

After Wayne pointed out I wasn't using the correct source, I've now bootstrapped this on a gcc-7.1 system (at the moment I'm trying to get it to run ALL the tests).

After that, I guess I'll confirm that it needs a lot more time, and space, to use its shipped llvm.

And then I'll see if I can persuade it to also install cargo (and revisit the tests, to see if I did get it to run them all).

But I'm marking this for 8.1 because it should be good enough to install firefox-56 and hopefully a few after that.

[ken@…]

When I first put rustc and cargo into the book, I expected that they would need to be upgraded frequently, and for that it looked as if using system LLVM-3 in /opt would save time, at least on the upgrades. But we have had three versions of firefox without needing to upgrade rust - the betas for ff56 need rust-1.17 which is one step on, moving to 1.19 will hopefully buy us some time.

There is good news and bad news.

Good:

A straight build of rustc can now install cargo without a separate build.

Also, the tests can now be made to run ALL the tests (although the order the various suites are run in still seems to be random, and I have doubts about whether the individual results add up to the number of tests to be run. There are 14029 tests. In 0.16.0, if the gdb tests were run without gdb, they failed, but if gdb was present some of them still failed. Now, they number of tests run is the same with or without gdb, and no failures from that.

Bad:

Yesterday I tested on a fast system from May (gcc-7.1) - one test loops forever (I gave up after 45 minutes on the first attempt), later I managed to confirm which test, and to delete it. In that case (only 14028 tests run) there were three failures - one (compile-fail/issue-37131.rs) - needs a compiler that supports thumbv6m-none-eabi and the BLFS build on an llvm-3.9 that only supports the host processor clearly doesn't, two others (codegen/mainsubprogram.rs and codegen/mainsubprogramstart.rs) are impenetrable, but the fact they fail looks worrying.

I also tried building with the shipped llvm (and for all targets) - that is a LOT bigger, and slower, but all tests pass.

Today I tried building on my 8.1-rc2 system: with the old-style configure-based build and LLVM from /opt/llvm3/bin, the tests hang in more than one place, and I failed to identify where they were hanging. But with the shipped llvm and all targets, all tests pass.

I then tried using the shipped LLVM but only building for the X86 target - again, all tests passed. This makes me suspicious that using separate shared LLVM might be miscompiling something.

On a 4-core processor, the reduced build for X86 uses 26 SBU and 3.2 GB (362 MB installed), the tests add 10 SBU and 1.4 GB.

Using the shipped LLVM, it is possible to do all the necessary configuration in config.toml, the old style --enable-llvm-link-shared would still require configure to be run.

At this point I haven't installed this (I've got an old version, and an ESR firefox, on this machine), but I'm inclined to use shipped LLVM for X86 (only) on my next build, and to put that in the book if firefox builds and works.

[bdubbs@…]

You have done a lot of work on this. I have not looked at it. I'll rely on your judgement for this package.

[ken@…]

On a fresh system it is working fine, but I had 3 failed commands in the tests:

compile-fail/issue-37131.rs and run-make/target-without-atomics both try to build for thumbv6m-none-eabi which of course is not available, I'm not sure how that seemed to pass on the first machine

and obviously I did have gdb installed on the first machine, because the third failure was debiginfo-gdb where all 105 tests failed.

But all 14029 tests were "run" and no hangs/CPU-burning-loops, so good to go.

[ken@…]

s/debiginfo-gdb/debuginfo-gdb/

[ken@…]

r19118