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 >>> >> annexc and run-conformtest still fail. cputimer1 passed.
> Same here. It might be interesting to compare our results of the > conformance tests. Here is what I have: > ISO... > ISO99... > ISO11... > POSIX... > XPG3... > Total number of tests : 3993 > Number of failed tests : 166 ( 4%) > Number of skipped tests : 89 ( 2%) > XPG4... > Total number of tests : 4175 > Number of failed tests : 29 ( <1%) > Number of skipped tests : 10 ( <1%) > UNIX98... > Total number of tests : 4701 > Number of failed tests : 14 ( <1%) > Number of skipped tests : 6 ( <1%) > XOPEN2K... > Total number of tests : 6825 > Number of failed tests : 13 ( <1%) > Number of skipped tests : 5 ( <1%) > XOPEN2K8... > Total number of tests : 7083 > Number of failed tests : 11 ( <1%) > Number of skipped tests : 1 ( <1%) > POSIX2008... > Total number of tests : 6305 > Number of failed tests : 7 ( <1%) > Number of skipped tests : 0 ( 0%) I have exactly the same numbers. >>> 075-binutils >>> >> ifunc.exp still fails. Searching google indicates a problem with the >> test, not the libraries or programs. > Actually, it is cured by the patch I sent yesterday. BTW, that patch is > needlessly complicated. It is just a matter of moving a brace from > one line to another. Which brace? ld-lib.exp line 1265? >>> 079-gcc >> I now get: >> >> FAIL: 22_locale/time_get/get_weekday/char/38081-2.cc execution test >> This indicates a problem with the ru_RU.UTF8 locale. I'm not >> sure why this fails. We haven't changed gcc, but it may be an issue >> with glibc-2.17 which installs the locales. >> >> FAIL: libmudflap.c++/pass55-frag.cxx >> ERROR: couldn't compile regular expression pattern: out of memory >> >> I have 3G of ram, but this is an extreme torture test. I don't know how >> much memory is actually needed. > Same here, with 4G of 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... > > 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... > > 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... > > Well, maybe not a big deal anyway... No, it's not a big deal because we don't use coreutils' login. We use the one from shadow. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
