[Clfs-dev] Trunk ppc : a final update from my Xmas build

Ken Moffat zarniwhoop at ntlworld.com
Thu Jan 17 16:42:44 PST 2008


On Sat, Jan 05, 2008 at 10:27:46PM +0000, Ken Moffat wrote:
> 
> 2. The gcc testsuite fails horribly: instead of 3 unexpected
> failures in gcc, and 1 in g++, I got 11951 in g++ (the order of the
> testing has changed), 30340 in gcc, 198 in libgomp, 520 in
> libmudflap, and the tests baild in libstdc++.  However, since then
> it has coped with all the code I've thrown at it, so I tend to
> assume that either there is something else needed in the basic
> infrastructure to run the tests (rather like the way libgcc_s had
> to be added), or else a minor change somewhere has totally borked
> the testsuites.
> 
 Hopefully, this is my last update about that troublesome build.
The test suite failures look more and more like a local error, but
I'm b?ggered if I know what was wrong.  On ppc64 (with the
PR31490 patch, and also in an earlier build without it) the test
results were in line with expectations (a few failures, but not
many).

 On a subsequent build of gcc using the branch_update-1 patch (in
case that was causing my runtime problems with X, which I later
traced to the ati 6.7.197 xorg driver), the results were again in
line with expectations.

 I'm currently in the middle of a fresh gcc test on ppc (just
building gcc on the 2007-12-23 system, with tcl, expect, dejagnu
added as part of my normal desktop) using the current book's patches,
and again it looks as if it will be "in line with expectations".
Certainly, gcc itself only had two failures this time, g++ had one,
and it's now burning cycles on libstdc++.

 Comparing my scripts for non-multilib and multilib (standard
scripts to create directories, do fake mounts, enter chroot), there
are minor differences (e.g. non-multilib explicitly tested for
/tools/lib/libstdc++.so.6 instead of /tools/lib/libstd* before
creating libstd* symlinks, and /dev/shm and /dev/pts were fake
mounted like they used to be), but nothing that looks likely to
have caused so many errors on that one build.  My scripts do things
differently from the book so that I can rerun them if I leave the
build and then resume it.  They are essentially unchanged (apart
from allowing fake mounts to report failure - hi, util-linux-ng )
in several months.  If I hadn't run the script, I wouldn't have got
in to chroot, so I'm fairly sure the symlinks were created.

 I'm about to write this off as "cannot repeat it, it now works for
me" and swear not to try building over Xmas this coming year.  But
what I still find really odd is that on that one run the gcc
testsuite started in g++, and then eventually attempted gcc itself -
normally, they are the other way around.

 Anyway, colour me baffled (unkind people may conclude that is my
normal state).  As always, suggestions for what might have gone
wrong will be welcome, real learning comes from understanding our
mistakes.

 I haven't tried anything other than ppc and ppc64 recently, but
those arches both look good at the moment - not all the test results
look 100%, but the resulting desktop systems seem fine.

 Hmm, maybe I should just try clfs-sysroot and forget about the
testsuites.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the Clfs-dev mailing list