[lfs-dev] LFS SVN current build results

Bruce Dubbs bruce.dubbs at gmail.com
Sat Dec 29 12:21:04 PST 2012


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





More information about the lfs-dev mailing list