[lfs-dev] Test failures in current svn

Ken Moffat zarniwhoop at ntlworld.com
Sun May 18 13:15:02 PDT 2014


On Sun, May 18, 2014 at 06:30:59PM +0200, Armin K. wrote:
> On 05/18/2014 01:53 AM, Ken Moffat wrote:

[ snipping to only the parts you commented on ]

> >  Since my build has stalled, I took the time to look at my test
> > results.  The following had failures (on x86_64) -
> > 
> > automake :
> > 
> > FAIL: t/lex-clean-cxx.sh
> > FAIL: t/lex-depend-cxx.sh
> > 
> 
> Latest svn should have this fixed by forcing usage of libfl.a instead of
> -lfl which defaults to shared lib.
> 

 Thanks, but I've got that and it is hasn't done the trick.

> > bc had the usual
> > 
> > binutils :
> > 
> >  ld-plugin failures (do we really want to enable this ?)
> > FAIL: PR ld/12758
> > FAIL: PR ld/12760
> > FAIL: LTO 3 symbol
> > FAIL: PR ld/13183
> > FAIL: LTO 3a
> > FAIL: LTO 11
> > 
> 
> gcc-4.9 issue I think. I believe archlinux has fix for this one.
> 

 Seems likely. But we now enable the lto plugin for gcc.  I cannot
tell if that is or is not wise until I can finish the system, but at
the moment I feel (slightly) concerned.

> > 
> > eudev :
> > 
> > 1 errors occurred, in udev-test.pl but I can't work out which test
> > it was.
> > I've seen the same thing in 1.5.4 : I append udev-test.pl.log to my
> > own log,
> > but it is full of lines like
> >  open /dev/null failed: No such file or directory
> > which don't really help and I cannot spot any _real_ error.
> > 
> 
> Same test fails in systemd too. Neither I have been able to figure it
> out. That's why I disabled it.
> 
 Cool - for eudev it is an upstream problem ;)

> > gcc :
> > 
> > FAIL: c-c++-common/tsan/thread_leak1.c
> > (several times, for different optimizations)
> > 
> > FAIL: gcc.c-torture/compile/limits-exprparen.c
> > (several times, for different optimizations, all of them ICEd)
> > 
> > FAIL: g++.dg/ipa/devirt-11.C
> > (several times, for different values of -std=)
> > 
> 
> I think latest patch modified something regarding ipa but I'm not sure.
> Maybe that caused it?

 Could be.  Again, what will really matter is the results for the
complete system.

 The two that most concern me are the new perl failures,
particularly the one that now gets undef.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce


More information about the lfs-dev mailing list