Ken Moffat wrote:
On Tue, Jul 26, 2016 at 02:19:21PM -0700, Paul Rogers wrote:
During the glibc tests, I was able to find the cause of the errors
with a quick search, so I knew they weren't a problem. I am unable to
determine whether the errors are serious or not.
The following is the result of piping "make check" to "grep FAIL":
I think the most prudent assumption is errors in glibc are "significant
until proven otherwise". But I fear you've "grepped-away" too much. My
recommendation would be to "tee" the console log during "make check"
(and "CMMI" too for that matter) to files, then use "less" to actually
look at what else the tests are trying to tell you with "/Error".
Paul, please look at the subject line - the failures were in
binutils, not glibc.
Noam,
for the first failure
FAIL: Link with zlib-gabi compressed debug output
the book says:
The test 'Link with zlib-gabi compressed debug output' is known to
fail.
In the -dev version of the book that has been removed because the test
appears to be gone. I get no failures in the most recent binutils.
But for the others I have no idea. I see that most, or all, of them
failures were releated to LTO (link-time optimization) [ as well as
the LTO tests I googled one of the pr tests you listed ] so
probably they happened during the ld tests and I wonder if my own
tests (x86_64, zero failures in binutils tests for any of my 4
different builds of LFS-7.9, and zlib-gabi did not fail for me)
perhaps did not run those tests for some reason.
The failures probably get documented in files, but without a
problematic build of my own I have no idea where those files might
be. All I can suggest is that you look at the full output, see
where it is running (i.e. which directory names) when the failures
are reported, and then look for those directories and see what they
contain.
Is there something odd about your hardware ? Nowadays, i686 tends
to count as odd because hardly anybody here builds recent LFS on it.
My only other comment is that I hope you were not running parallel
make for the tests (e.g. -j4) - on gcc that used to work, and the
contrib script would then massage the results into order, but in the
last year or two I got all manner of weird failures in gcc/g++ tests
so I now always use -j 1 for 'make check' except in automake where
the book specifies -j4. For normal runs of make I continue to use
-jN where N is between 2 and 8, it's only in the testsuites that I
expect problems.
Sorry I don't have any useful suggestions.
The only thing I can think of is that there was some mistake made in
Chapter 5, The only other possibility is some sort of host system kernel
issue, but that is quite unlikely.
The standard advice in this area is to wipe /mnt/lfs (except sources of
course) and start over.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
