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 _______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
