On Mon, 15 Aug 2005, J.R. Hass wrote: > Hi folks, > > Hopefully someone can help me here. I have reached the building of gcc > in chapter 6. I have done everything by the book; I have not deviated > at all. Jim in IRC was nice enough to look at the log of the output, > and noticed I was having a date issue (it was complaining about a > modification time). Once I set the date up that complaint went away, > but I'm still getting all failures.
> WARNING: Couldn't find the global config file. That part is normal > Test Run By root on Sun Aug 7 21:29:19 2005 > Native configuration is i686-pc-linux-gnu > > === gcc tests === > > Schedule of variations: > unix > > Running target unix > Using /tools/share/dejagnu/baseboards/unix.exp as board description > file for target. > Using /tools/share/dejagnu/config/unix.exp as generic interface file for > target. > Using /sources/gcc-3.4.3/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running /sources/gcc-3.4.3/gcc/testsuite/gcc.c-torture/compile/compile.exp ... > FAIL: gcc.c-torture/compile/20000105-1.c -O0 (test for excess errors) > FAIL: gcc.c-torture/compile/20000105-1.c -O1 (test for excess errors) > FAIL: gcc.c-torture/compile/20000105-1.c -O2 (test for excess errors) > FAIL: gcc.c-torture/compile/20000105-1.c -O3 -fomit-frame-pointer > (test for excess errors) > FAIL: gcc.c-torture/compile/20000105-1.c -O3 -fomit-frame-pointer > -funroll-loops (test for excess errors) > FAIL: gcc.c-torture/compile/20000105-1.c -O3 -fomit-frame-pointer > -funroll-all-loops -finline-functions (test for excess errors) > *some* failures in the torture tests are often normal, although I see that in gcc itself I only had one unexpected failure in my last i686 build of 3.4.3. > > and then it just continues with hundreds and hundreds of failures. The > only thing I can see is the warning of a missing a global config file. > I'm not sure if that's normal or not. Any suggestions would be most > appreciated. Thanks! > Sounds bad. I can remember seeing something similar a few months ago when I was first grappling with LFS-6.0 on a ppc box. I think I made a mistake in setting up the environment with my scripts, but I don't have the details any more. A search on the archives of lfs-hackers suggests the permissions on /dev/null were wrong. Let's start by checking if all of the expected devices are in /dev with the expected permissions (section 6.8.2) and confirming that /dev/pts and /dev/shm are mounted from inside chroot. (Perhaps you powered off before reaching gcc, and missed some of this when you resumed). If those look ok, which kernel version are you running ? (Greg Schafer reported an address space randomization issue with g++ (3.4.x) precompiled headers, but it should only affect 2.6.12 kernels and the pch tests as I read it). He documented it with references at http://www.diy-linux.org/pipermail/diy-linux-dev/2005-July/000595.html Ken -- 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
