On Mon, May 14, 2012 at 10:56:10PM +0430, Yasser Zamani wrote: > > Is this failure expected or is a fatal error (and the process could not be > continued before resolving it)?! Or do you think that eliminating '-j2' > switch will resolve it (I should know before trying because it's test take 31 > minutes to complete(i.e. 1 hour without -j2!))? > > Thanks in advance! > > -Yasser >
A few general points, since I don't have any test results from 7.1 handy (I generally only run full tests when building a new set of versions, and I've upgraded to new machines after confirming 7.1 was good) : 1. For me, there are often occasional test failures. Some of these are caused by my deviations from the book (avoiding as many static libraries as I can), others are probably down to different hardware, or even different kernel versions. When we were first able to run tests (LFS-5, if my memory is correct), it looked very useful - in LFS-4 I remember some people had apparently inexplicable build failures. In practice, most test failures are not particularly useful in diagnosing that anything is wrong: more often, it's a shortcoming of the test. Also, even if all the tests pass 100%, it says nothing about whether the resulting system will be good enough (see recent posts on lfs-dev about unpatched glibc). So, if you have *many* test failures, it can indicate a problem. For people making changes to the book, particularly to how packages are built, or to the build order, changes in detailed failure results can be very informative - I remember a problem in early cross-lfs which I traced to a different build order. For everyone else, use a pinch of salt. 2. We know you are developing scripts. I will venture to suggest that when moving to scripts, or when making major changes in how your scripts work, it is useful to keep your previous results so that you know if a test failure is a difference : if it isn't, you can ignore it for the purposes of validating the scripts. If it is different, see point (1.) and, if you care enough, try googling to see if anyone else has found the problem recently, and any solutions or explanations offered. 3. If it only takes an hour to rerun make -j1 check, it's probably going to be more efficient for you to try that rather than wait for mailing list responses. I've only recently got multiprocessor desktops ( on my old single processor machines, make -j2 often took longer then make -j1 ) and so far I've found about half a dozen packages in my whole desktop build where make -j1 is needed. Often, the results are obvious, but occasionally the failures are sporadic with very misleading error messages. The other problem with using make -j1 in *tests* is that the results might be mixed together (e.g. gcc, where using contrib/test_summary makes the results comprehensible). So, if your machine has CPU cycles to spare, *trying* multiple makes or checks is worthwhile. But if the build or tests fail, or if the test logs are too garbled to be useful, you will need to be prepared to retry with a single make. In this case, "your scripts, your results" :) ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
