[lfs-support] glibc tests on a VIA nano processor: 2 unexpected failures

Hazel Russman hazeldebian at googlemail.com
Mon Jan 23 04:35:10 PST 2017


On Sun, 22 Jan 2017 16:10:06 -0600
"Douglas R. Reno" <renodr2002 at gmail.com> wrote:

> On Sun, Jan 22, 2017 at 3:41 PM, Hazel Russman <hazeldebian at googlemail.com>
> wrote:
> 
> > On Sun, 22 Jan 2017 12:55:56 -0600
> > Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> >  
> > > Hazel Russman wrote:  
> > > > I am building LFS on a Sony laptop. It is the first LFS I have built on
> > > > this machine, in fact the first I have ever built for a non-intel
> > > > processor.
> > > >
> > > > There are 8 failures in the glibc tests, mostly in math (which the book
> > > > suggests are to be expected on non-intel/non-amd chips). The 2 getaddr
> > > > failures are also expected. But I also have fails in csu/test-multiarch
> > > > and nss/test-netdb. Are these significant?  
> > >
> > > That's hard to say without analyzing the actual failures.  However 8
> > > failures out of 2500 tests in a complex library like glibc is probably  
> > not  
> > > significant.  The tests most likely make some implicit assumptions that
> > > the processor does not satisfy.
> > >
> > >    -- Bruce  
> > I have now checked the out files. nss/netdb gets timed out. I shall try it
> > again with TIMEOUTFACTOR set and see if that makes any difference.
> >
> > csu/test-multiarch fails to find one of the cpu's architecture flags.
> > [code]
> > Checking HAS_CPU_FEATURE (SSSE3):
> >   init-arch 0
> >   cpuinfo (ssse3) 1
> >  *** failure ***
> > [code]
> >
> > /proc/cpuinfo shows ssse3 flag is set.
> > @Douglas Reno: This also shows that /proc directory is correctly mounted.
> >  
> 
> OK, I just wanted to make sure of that. A thread on LQ suggested it.
> 
> I'd hope that it isn't actually trying to use that flag in the compiler.
> That could lead to a sticky situation of unexecutable code.
I would have thought the reverse was true. My cpu seems to have a capacity which gcc has not recognised, and consequently glibc has not been configured to use it. That might lead to inefficient code, but not to unrecognised commands. Surely the really dangerous situation would be the reverse, with glibc assuming a flag that wasn't there.

I'm making the assumption that compiler flags indicate positive capacities and not warnings. I must admit that I know very little about hardware; I could do with some reassurance here.

I have now repeated the tests with TIMEOUTFACTOR=16 and make -j1. This gets rid of the nss/test-netdb failure, but the csu/test-multiarch failure is still there.

-- 
If any members of GCHQ are reading this, shame on you! I fought for your right to belong to a trade union and now you are taking away my right to privacy?

H Russman


More information about the lfs-support mailing list