On Jul 27, 2016 12:46 AM, "Bruce Dubbs" <[email protected]> wrote: > > 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 > > I'd check your RAM as well. Had a few times on an old i686 machine where flaky RAM could cause issues like this.
Douglas R. Reno
-- 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
