linux-from-scratch/glfs
1
0
Fork 0
mirror of https://github.com/Zeckmathederg/glfs.git synced 2025-02-03 23:07:23 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Various rewording in rustc:

Browse Source 
Primarily, do not indicate that a few tests should be ignored.
Without gdb, or with gdb-9.2, only two testsreliably failed.
But with gdb-10.1, which is newer than this version of rust,
four extra failures have appeared because of changes in gdb.
We hold on to versions of rust, but we update gdb when that is
issued, so it semes likely that the number of failures from
newer gdb may increase. Ratherthan play whack-a-mole with
extra seds as tests are reproted to now fail, let them fail.

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@23857 af4574ff-66df-0310-9fd7-8a98e5e911e0
This commit is contained in:
Ken Moffat 2020-11-01 00:35:23 +00:00
parent 84b29baf2a
commit 925dbb2afe
1 changed files with 15 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
general/prog/rust.xml
View File

@ -129,9 +129,7 @@
<para> <para>
Rustc defaults to building for ALL supported architectures, using a Rustc defaults to building for ALL supported architectures, using a
shipped copy of LLVM. In BLFS the build is only for the X86 shipped copy of LLVM. In BLFS the build is only for the X86
architecture. Rustc still claims to require Python 2, but that is only architecture.
really necessary when building some other architectures with the
shipped LLVM.
If you intend to develop rust crates, this build may not be good If you intend to develop rust crates, this build may not be good
enough for your purposes. enough for your purposes.
</para> </para>
@ -301,15 +299,6 @@ EOF</userinput></screen>
<screen><userinput remap="pre">patch -Np1 -i ../rustc-&rust-version;-llvm9_fixes-1.patch</userinput></screen>--> <screen><userinput remap="pre">patch -Np1 -i ../rustc-&rust-version;-llvm9_fixes-1.patch</userinput></screen>-->
<para>
Two of the tests reliably fail. To cause them to be ignored run the
following sed command:
</para>
<screen><userinput>sed -i '1i # ignore-test' \
src/test/run-make-fulldeps/sysroot-crates-are-unstable/Makefile \
src/test/run-make-fulldeps/long-linker-command-lines/Makefile</userinput></screen>
<para> <para>
Compile <application>Rust</application> by running the following Compile <application>Rust</application> by running the following
commands: commands:
@ -336,12 +325,17 @@ python3 ./x.py build --exclude src/tools/miri</userinput></screen>
</para> </para>
<para> <para>
Although no tests are now expected to fail, on an apparently successful At a minimum, two tests (run-make-fulldeps/long-linker-command-lines
build (gdb not installed) the testsuite reports that and run-make-fulldeps/sysroot-crates-are-unstable) may fail.
1 commands did not execute successfully. If a version of <command>gdb</command> which was released after this
<!-- As with all large testsuites,--> version of rust is used, such as <xref linkend="gdb"/>, four more failures
Some tests might (debuginfo/extern-c-fn.rs, debuginfo/generator-objects.rs,
fail on some machines - if the number of failures is in the single digits, debuginfo/issue-57822.rs, debuginfo/pretty-huge-vec.rs) can be expected.
</para>
<para>
As with all large testsuites, other tests might fail on some machines -
if the number of additional failures is in the single digits,
check the log for 'FAILED' and review lines above that, particularly the check the log for 'FAILED' and review lines above that, particularly the
'stderr:' lines. Any mention of 'stderr:' lines. Any mention of
SIGSEGV or signal 11 in a failing test is a cause for concern. SIGSEGV or signal 11 in a failing test is a cause for concern.
@ -351,7 +345,7 @@ python3 ./x.py build --exclude src/tools/miri</userinput></screen>
If you get any <emphasis>other</emphasis> failing test which reports an If you get any <emphasis>other</emphasis> failing test which reports an
issue number then you should search for that issue. For example, when issue number then you should search for that issue. For example, when
rustc &gt;= 1.41.1 was built with a version of sysllvm before 10.0 the test rustc &gt;= 1.41.1 was built with a version of sysllvm before 10.0 the test
for issue 69225 fails <ulink for issue 69225 failed <ulink
url="https://github.com/rust-lang/rust/issues/69225"/> and that should be url="https://github.com/rust-lang/rust/issues/69225"/> and that should be
regarded as a critical failure (they released 1.41.1 because of it). regarded as a critical failure (they released 1.41.1 because of it).
Most other failures will not be critical. Most other failures will not be critical.
@ -459,9 +453,10 @@ cp -a install/* /</userinput></screen>
has failed to build on releases. It is optional, but the failure has failed to build on releases. It is optional, but the failure
messages can persuade people that the whole build failed. However, messages can persuade people that the whole build failed. However,
although it is not built in the main compile, with rustc-1.35.0 it although it is not built in the main compile, with rustc-1.35.0 it
now gets compiled during the install, but it is broken in this version. now got compiled during the install, but it was broken in that version.
<!-- might be unbroken in 1.36.0, if so remove broken from description <!-- might be unbroken in 1.36.0, if so remove broken from description
of miri below. https://github.com/rust-lang/rust/issues/61830 --> of miri below. https://github.com/rust-lang/rust/issues/61830 -->
Omitting it should save a little time.
</para> </para>
<para> <para>