[lfs-dev] Test failures in something close to current LFS

Ken Moffat zarniwhoop at ntlworld.com
Fri Jan 30 15:57:12 PST 2015

On Fri, Jan 30, 2015 at 05:27:11PM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> >On Thu, Jan 29, 2015 at 12:23:56AM +0000, Ken Moffat wrote:
> >>
> >>gcc: 125 unexpected failures in g++, 658 in gcc, 22 in libstdc++
> >>instead of the usual handful of failures.  The last time I saw those
> >>sorts of numbers was a little while before my AmigaOne expired.
> >>
> >  I wonder if some of it was because my tmpfs for /tmp was too small.
> >I thought I was using 6GB, but I was on my 7.6 system when I set
> >that up, the November system I used to build the new one was still
> >using only 2GB for /tmp.
> >
> >  I've now rebuilt gcc on the completed system, again using only 2GB
> >for the tmpfs.  This time, the results were a little better - only
> >83 unexpected failures in gcc, and 42 in g++, none in libstdc++.
> >In both cases, I used -j4.
> I did a jhalfs build yesterday and got 2 unexpected successes and no
> unexpected failures for gcc-4.9.2.
> I used -j10 and it completed in Totalseconds: 1252 (about 21 minutes).
> >  So, for the moment I'm just going to flag this up as "looks
> >serious, unexplained, but so far I do not see any problems in the
> >resulting system."
> I'll just state the obvious.  Did you run out of ram?  Is it in chroot?  Are
> all the virtual filesystems available?
> I can send you my logs if you want.

 It is still _possible_ that I ran out of RAM.  The first time was
in chroot, with all virtual filesystems.  The second, as a user on a
completed system.  Unfortunately, I could not find any _output_ from
the gcc tests, only several directories of summaries.  I did save
those, just in case somebody tells me where/what I need to look at.

 My initial concern was that something in the 3.19-rc headers might
be causing a problem, but I see no evidence for that.

> >  And for what it is worth, 6GB is not enough to build firefox in
> >/tmp - I had to drop down to 4GB to get enough space for the link,
> >as well as building on a disk (the build in 6GB was using over 5GB
> >plus whatever the link wanted).
> Hmm.  My last build had:
> du -sh firefox
> 4.6G    firefox
> That was version 32.0.1 on one system.
> 2095.7 Elapsed Time -  firefox-32.0.1.source
> SBU=17.464
> 146524 /usr/src/firefox/firefox-32.0.1.source.tar.bz2 size (143.089 MB)
> 4823172 kilobytes build size (4710.128 MB)
> Do you need me to do the latest for comparison?
>   -- Bruce
 No, I don't think it would help.  This is x86_64, i686 is always
smaller and from memory (watching 'top') the link ('ld') near the
end of the firefox build used to use just over 2GB.  New versions
of firefox are usually bigger, and slower to build.  Actually, some
of the output from ld might be included in my measurement, I don't
believe that any file in the completed build is close to 2GB.

  Anyway, that build in a tmpfs was only an attempt to speed up my
builds without replacing the machine.  I'll try a small SSD (I only
have 3GB/s SATA-2 on this mobo) just for the builds and for qemu
backing images once I've got a bit further.

Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.

More information about the lfs-dev mailing list