On Sat, 2012-12-29 at 20:51 +0100, Pierre Labastie wrote: > Did a test build too. I applied the patch I sent yesterday for binutils. > > Le 29/12/2012 02:41, Bruce Dubbs a écrit : > > Following up with results from a build of SVN-20121228 > > > >> 071-glibc
Same failures and conformance test numbers here. > >> 075-binutils Same failure in ifunc.exp. > >> 079-gcc I get: ERROR: g++.dg/abi/mangle33.C -std=c++98: error executing dg-final: couldn't compile regular expression pattern: out of memory ERROR: g++.dg/abi/mangle33.C -std=c++11: error executing dg-final: couldn't compile regular expression pattern: out of memory in addition to your 22_locale/time_get/get_weekday/char/38081-2.cc failure. I also get: FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test And then: ERROR: tcl error sourcing /sources/gcc-4.7.2/libmudflap/testsuite/libmudflap.cth/cthfrags.exp. ERROR: couldn't compile regular expression pattern: out of memory These are all on a laptop with 3G RAM. > I also got a failure in the coreutils test suite: > FAIL: test-getlogin > =================== > test-getlogin.c:48: assertion failed > > I think the assertion is ASSERT(isatty (0)), which of course is false > when running jhalfs. > Actually, that assertion is changed from ASSERT(! isatty (0)) to > ASSERT(isatty (0)) by the sed in the book. > > So that, after the sed, the chunk of C code is: > ASSERT (isatty (0)); > fprintf (stderr, "Skipping test: stdin is not a tty.\n"); > return 77; > which is kind of contradictory... Yeah, that dates back to when I couldn't get to the bottom of that failure, so hacked it to stop it complaining. > Thinking more about it, there is no way to have that assertion > work in all cases in LFS: > The reason is that getlogin returns NULL and raises the error > ENOENT when utmp cannot be read (according to man getlogin). > But utmp does not exist in the chroot environment! > it is created dynamically in /var/run by the bootscripts... Well, an empty utmp file is created by the bootscripts. According to utmp(5), it's agetty(8) or login(1) that will update it. So, to get it to be correctly populated, I think we'd have to create /mnt/lfs/var/run/utmp from the host first, then hopefully the method we use to enter the chroot environment is enough to trigger the population of that file! All that said... > Then comes the ASSERT(isatty (0)) (or the negated one in the > original test). If you are running tests interactively, it does not > fail but says wrongly that the test is skipped because of input > not being a tty. If you do not run them interactively, it fails... I think this will trip us up, as some people will script their builds, others won't. I'll take another look at this tomorrow, once my latest build is done. Cheers, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
