Author: ken Date: Thu Jan 24 11:09:29 2019 New Revision: 21033 Log: Rustc-1.32.0. I've moved the Note about only updating when necessary into the introduction as ordinary text, added some details about deleting an older version before updating, and reworked the text about testing. That might still need a little tweaking, but best to get the updated instructions out because people have been having trouble interpreting their results. Thanks to all the people who have helped on this version, both here and on the issues at rust.
Modified: trunk/BOOK/general/prog/rust.xml trunk/BOOK/introduction/welcome/changelog.xml trunk/BOOK/packages.ent Modified: trunk/BOOK/general/prog/rust.xml ============================================================================== --- trunk/BOOK/general/prog/rust.xml Thu Jan 24 10:30:47 2019 (r21032) +++ trunk/BOOK/general/prog/rust.xml Thu Jan 24 11:09:29 2019 (r21033) @@ -6,10 +6,15 @@ <!ENTITY rust-download-http "https://static.rust-lang.org/dist/rustc-&rust-version;-src.tar.gz";> <!ENTITY rust-download-ftp " "> - <!ENTITY rust-md5sum "6790c24fe5e8fb5a5f7efbfbcc6fea65"> - <!ENTITY rust-size "101 MB"> - <!ENTITY rust-buildsize "6.5 GB (679 MB installed) including 270MB of ~/.cargo files for the user building this (add 1.4GB if running the tests)"> - <!ENTITY rust-time "27 SBU (add 13 SBU for tests, both with 4 processors)"> + <!ENTITY rust-md5sum "366f049777e00d0d6f15d25895485efb"> + <!ENTITY rust-size "152 MB"> + <!-- Gentle Reminder: buildsize is how much the user requires for the real + install, i.e. the source with its DESTDIR *plus* the DESTDIR. You + can 'mkdir /tmp/RUST ; cp -a install/* /tmp/RUST' and then run 'du -sch' + to measure it. --> + + <!ENTITY rust-buildsize "6.2 GB (475 MB installed) including 295MB of ~/.cargo files for the user building this. Add 1.5GB if installing the documentation (an extra 314MB is installed), and 2.0GB if running the tests"> + <!ENTITY rust-time "34 SBU (add 3 SBU if installing the documentation and 15 SBU for tests, both with 4 processors)"> ]> <sect1 id="rust" xreflabel="rustc-&rust-version;"> @@ -35,6 +40,14 @@ </para> <para> + This package is updated on a six-weekly release cycle. Because it is + such a large and slow package to build, and is at the moment only required + by five packages in this book, the BLFS editors take the view that it + should only be updated when that is necessary (either to fix problems, + or to allow a new version of <application>firefox</application> to build). + </para> + + <para> As with many other programming languages, rustc (the rust compiler) needs a binary from which to bootstrap. It will download a stage0 binary and many cargo crates (these are actually .tar.gz source archives) at @@ -43,6 +56,32 @@ </para> <para> + These crates will then remain in various forms (cache, directories of + extracted source), in <filename class="directory">~/.cargo</filename> for + ever more. It is common for large <application>rust</application> packages + to use multiple versions of some crates. If you purge the files before + updating this package, very few crates will need to be updated by the + packages in this book which use it (and they will be downloaded as + required). But if you retain an older version as a fallback option and + then use it (that would require <emphasis>not</emphasis> building in + <filename class="directory">/usr</filename>), it is likely that it will + then have to re download some crates. For a full download (i.e. starting + with an empty or missing <filename class="directory">~/.cargo</filename>) + downloading the external cargo files for this version only takes a minute + or so on a fast network. + </para> + + <note> + <para> + When you upgrade to a newer version, the new libraries will have various + hashes in their names and therefore there will be a mix of versions but + only one of each will be usable. A binary distribution would use its + package manager to delete all the old <application>rust</application> + installation before updating. You may wish to do the same to save space. + </para> + </note> + + <para> The current <application>rustbuild</application> build-system will use all available processors, although it does not scale well and often falls back to just using one core while waiting for a library to compile. @@ -62,10 +101,8 @@ purposes. </para> <para> - Repeated builds of this package on the same machine show a wide range - of build times. Some of this might be due to variations in downloading - the required cargo files if they are not already present, but this does - not seem to adequately explain the variations. + Unlike with previous versions, the build times of this version when + repeated on the same machine seem reasonably consistent. </para> <para> Unusually, a DESTDIR-style method is being used to install this package. @@ -122,15 +159,16 @@ <xref linkend="python2"/> </para> +<!-- comment out while using shipped LLVM <bridgehead renderas="sect4">Recommended</bridgehead> <para role="recommended"> <package>clang</package> from <xref linkend="llvm"/> (built with -DLLVM_LINK_LLVM_DYLIB=ON) - </para> + </para>--> <bridgehead renderas="sect4">Optional</bridgehead> <para role="optional"> - <xref linkend="gdb"/> (recommended if running the testsuite) + <xref linkend="gdb"/> (used by the testsuite if it is present) </para> <para condition="html" role="usernotes"> @@ -141,34 +179,37 @@ <sect2 role="installation"> <title>Installation of Rust</title> - <note> - <para> - This package is updated on a six-weekly release cycle. Because it is - such a large and slow package to build, and is at the moment only required - by five packages in this book, the BLFS editors take the view that it - should only be updated when that is necessary. - </para> - </note> - <para> - First create a suitable <filename>config.toml</filename> file - which will configure the build : + First create a suitable <filename>config.toml</filename> file which will + configure the build. Unlike with previous releases, where even quite old + system versions of <application>LLVM</application>worked well, this + version ships with a development version and using the current <xref + linkend="llvm"/> release is known to result in breakage in some + circumstances. </para> <screen><userinput>cat << EOF > config.toml # see config.toml.example for more possible options [llvm] -targets = "X86" -# When using system llvm prefer shared libraries -link-shared = true +# use ninja +ninja = true + +targets = "X86" +# When compiling LLVM, the experimental targets (WebAssembly +# and RISCV) are built by default - omit them +experimental-targets = "" [build] +# omiti HTML docs to save time and space (comment this to build them) +docs = false + # install cargo as well as rust extended = true [install] prefix = "/usr" +# docdir is used even if the full awesome docs are not installed docdir = "share/doc/rustc-&rust-version;" [rust] @@ -179,11 +220,8 @@ # so disable codegen tests codegen-tests = false -[target.x86_64-unknown-linux-gnu] -# delete this *section* if you are not using system llvm. -# NB the output of llvm-config (i.e. help options) may be -# dumped to the screen when config.toml is parsed. -llvm-config = "/usr/bin/llvm-config" +# get a trace if there is an Internal Compiler Exception +backtrace-on-ice = true EOF</userinput></screen> @@ -193,13 +231,7 @@ </para> <screen><userinput>export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" && -./x.py build</userinput></screen> - - <para> - The build will report it failed to compile <filename>miri</filename> - because of multiple potential crates for `log`, but that should be followed - by a message that the build completed successfully. - </para> +./x.py build --exclude src/tools/miri</userinput></screen> <note> <para> @@ -207,35 +239,42 @@ <phrase revision="sysv">system log</phrase> <phrase revision="systemd">systemd journal</phrase> for traps on invalid opcodes, and for segmentation faults. - In themselves these are nothing to worry about, although if the - output from the testsuite reports tests which FAIL with such faults - then there may be a problem. + In themselves these are nothing to worry about, just a way for the + test to be terminated. But if the output from the testsuite reports tests + which FAIL with segmentation faults (signal 11) then there may be a + problem. </para> </note> <para> To run the tests issue <command>./x.py test --verbose --no-fail-fast | tee rustc-testlog</command>: - as with the build, that will use all available CPUs. This runs many suites - of tests (in an apparently random order), several will fail in BLFS: - compile-fail/issue-37131.rs require a thumbv6m-none-eabi compiler but the - BLFS build does not cater for - that, ui/issue-49851/compiler-builtins-error.rs and ui/issue-50993.rs (both - run twice) require a thumbv7em-none-eabihf compiler, and seven tests in - debuginfo-gdb will fail because gdb-8.1 changed the output format. If - <application>gdb</application> has not been installed, most of the gdb tests - will fail. + as with the build, that will use all available CPUs. + </para> + + <para> + The instructions above do not build ARM compilers, so the testsuite + <emphasis>will</emphasis> fail and the tests will be reported to end in + error, with a backtrace of the last failing test. On a good run, 3 tests + which need Thumb (ARM) compilers will fail, all in <filename + class="directory">ui/issues</filename> for issues 37131, 49851 and 50993. + Occasionally a fourth test, in run-make, 'sysroot-crates-are-unstable', + has been known to fail. That is probably harmless. As with all large + testsuites, other tests might fail on some machines - if the number of + failures is in the single digits, check the log for 'FAILED' and review + lines above that. Any mention of SIGSEGV or signal 11 in a failing test + is a cause for concern. </para> <para> - If you wish to look at the numbers for the results, you can find the total - number of tests which were considered by running: + Therefore, you should determine the number of tests, failures, etc. The + total number of tests which were considered is found by running: </para> <screen><command>grep 'running .* tests' rustc-testlog | awk '{ sum += $2 } END { print sum }'</command></screen> <para> - That should report 17101 tests. Similarly, the total tests which failed can + That should report 15795 tests. Similarly, the total tests which failed can be found by running: </para> @@ -244,7 +283,7 @@ <para> And similarly for the tests which passed use $4, for those which were ignored (i.e. skipped) use $8 (and $10 for 'measured', $12 for 'filtered out' but both - are probably zero). The breakdown does not match the overall total. + are probably zero). The breakdown does not quite match the overall total. </para> <para> @@ -293,6 +332,7 @@ even if they have been deleted from there after the install. </para> + <!-- comment while using shipped LLVM <para> <command>[target.x86_64-unknown-linux-gnu]</command>: the syntax of <filename>config.toml</filename> requires an <literal>llvm-config</literal> @@ -301,7 +341,7 @@ on 32-bit x86. This whole section may be omitted if you wish to build against the shipped llvm, or do not have clang, but the resulting build will be larger and take longer. - </para> + </para>--> <para> <command>export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi"</command>: @@ -311,6 +351,13 @@ </para> <para> + <command>--exclude src/tools/miri</command>: For a long time, the miri + crate (an interpreter for the Midlevel Intermediate Representation) + has failed to build on releases. It is optional, but the failure + messages can persuade people that the whole build failed. + </para> + + <para> <command>--verbose</command>: this switch can sometimes provide more information about a test which fails. </para> Modified: trunk/BOOK/introduction/welcome/changelog.xml ============================================================================== --- trunk/BOOK/introduction/welcome/changelog.xml Thu Jan 24 10:30:47 2019 (r21032) +++ trunk/BOOK/introduction/welcome/changelog.xml Thu Jan 24 11:09:29 2019 (r21033) @@ -45,6 +45,15 @@ <para>January 24th, 2019</para> <itemizedlist> <listitem> + <para>[ken] - Update to rustc-1.32.0, needed for the forthcoming + firefox-65. Note that the instructions are going to be changed to + install in /opt/rustc-1.XX.Y but the details of that are yet to be worked + through. The intention is that people will not have to rebuild just + because the book changes to using /opt. This build reverts to using the + shipped LLVM because system llvm-7.0.1 is too old. This addresses <ulink + url="&blfs-ticket-root;11521">#11521</ulink>.</para> + </listitem> + <listitem> <para>[pierre] - Update volume_key dependencies and instructions, to avoid using Python 2.</para> </listitem> Modified: trunk/BOOK/packages.ent ============================================================================== --- trunk/BOOK/packages.ent Thu Jan 24 10:30:47 2019 (r21032) +++ trunk/BOOK/packages.ent Thu Jan 24 11:09:29 2019 (r21033) @@ -337,7 +337,7 @@ <!ENTITY ruby-minor-version "2.6"> <!ENTITY ruby-patch-version "0"> <!ENTITY ruby-version "&ruby-minor-version;.&ruby-patch-version;"> -<!ENTITY rust-version "1.29.2"> +<!ENTITY rust-version "1.32.0"> <!ENTITY scons-version "3.0.4"> <!ENTITY slang-version "2.3.2"> <!ENTITY subversion-version "1.11.1"> -- http://lists.linuxfromscratch.org/listinfo/blfs-book FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
