#9652: rustc-1.19.0
-------------------------+-----------------------
Reporter: ken@… | Owner: ken@…
Type: enhancement | Status: assigned
Priority: normal | Milestone: 8.1
Component: BOOK | Version: SVN
Severity: normal | Resolution:
Keywords: |
-------------------------+-----------------------
Comment (by 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.
--
Ticket URL: <http://wiki.linuxfromscratch.org/blfs/ticket/9652#comment:2>
BLFS Trac <http://wiki.linuxfromscratch.org/blfs>
Beyond Linux From Scratch
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
