On 8/21/20 4:40 PM, Ken Moffat via lfs-dev wrote:
I've now run the full set of tests on three different builds of
10.1-rc1, and I'm almost in agreement about the expected results.
Two builds were on ryzen. Those used -O3 throughout, even in gcc
where I had stopped doing that because of failures I described as in
the torture tests. Reinstated because on a semi-decent development
machine I want to build more quickly. The other build was one my i3
skylake using -O2 - it's not a main development machine.
For testing purposes, I have three systems running 10.0-rc1 at the
moment as well. One of them is a Skylake i5 (which I'll use for replying
with test results here), another is an old AMD Turion 64 X2-based
system, and another is an Intel CoreDuo (for i686).
The following packages still cause me to query what the book says:
tcl: I still think that the line
Files with failing tests: http.test httpold.test
should be mentioned in addition to the clock test (which exits with
errors).
I agree on that. It seems to be transient, because I've seen it on one
x86_64 system but not another (The Turion 64 X2 that I use for
Synaptics+ATI has that line, but my Skylake box doesn't).
gcc: I get two additional failures in libstdc++ on all three
machines,
FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
FAIL: 22_locale/numpunct/members/char/3.cc execution test
I didn't get a FAIL for
20_util/unsynchronized_pool_resource/allocate.cc, but I did for numpunct
on all three of my systems that have built 10.0-rc1 so far (soon to be a
fourth for the VMWare driver):
=== libstdc++ tests ===
Running target unix
FAIL: 22_locale/numpunct/members/char/3.cc execution test
FAIL: 22_locale/time_get/get_time/char/2.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
Totals for unexpected failures in my builds:
-O2 -O3
g++ 17 17 and 18
gcc 7 21
libstdc++ 8 8
So, using -O3 still breaks some more gcc torture tests (but the
build seems to work well). But I think those two extra libstdc++
failures ought to be mentoned.
Python: for me, test_normalization passed on each build. Not sure
if it still fails for you guys ?
On the one system I built manually, it did fail for me. However I do
think it should be re-evaluated because it's very likely that I missed
something.
coreutils: We say test-getlogin is known to fail, but in each of my
builds I have:
SKIP: test-getlogin
SKIP: test-getlogin
I concur on that, I think that needs to be updated.
util-linux: we pass -k to make check without specifying any details.
For me, column/invalid multibyte failed on each of my builds.
column: invalid multibyte ... FAILED
(column/invalid-multibyte)
ipcs: mk-rm-msg ... FAILED
(ipcs/mk-rm-msg)
ipcs: mk-rm-sem ... FAILED
(ipcs/mk-rm-sem)
ipcs: mk-rm-shm ... FAILED
(ipcs/mk-rm-shm)
I had some more tests fail on at least one of my systems. We should
definitely document these better.
Apart from these minor details of what to expect, this is now all
looking really good. I'll also mention that for inetutils, where
libls _may_ fail, it failed on the O2 build and one of the O3
builds, but not on the other O3 build.
That failure really seems like a transient failure to me. I had one
system fail it, but the other two passed it. I'm not sure what causes that
- Doug
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
