[lfs-support] glibc test failures. Acceptable?

Ken Moffat zarniwhoop at ntlworld.com
Mon Oct 28 11:14:26 PDT 2013


On Mon, Oct 28, 2013 at 04:25:02PM +0000, Richard wrote:
> 
> I think I neglected to shut down the networking on the host system - so the posix tests did not fail. I did not realise that network isolation was a requirement. I do not have that machine with me here at work - so I will check later.
> 

 That is interesting.  And very puzzling.  For me, I don't shut down
networking on the host (why would anyone do that ?), but I think that
test has always failed for me since it was introduced - it's fairly
recent.

 Similarly, I get an ignored Error for posix/annexc.out and I think
that one has been like that ever since we've been running the tests
('pure LFS' - first release like that was 5.0 if my memory is
correct), but I didn't see that one either in your grep.

> >
> > > I am also assuming that glibc is one of the packages that can safely be installed to a fake root - then tarballed 'slackware style'? (i.e: I am intending that my next step would be make DESTDIR=dest install), rather then installing directly.
> > >
> > 
> > For the first time, we recommend doing things by-the-book so that
> > you understand how it all fits together.  If you wish to try doing
> > things differently, please be aware that you *might* encounter
> > problems that other people don't.
> 
> I'll probably get shouted at for this - but here goes...
> 
> ... forgive my stupidity. I was trying to stick to doing things by the book.
> The method of installing to a fake destination directory is explained in sections
> 6.3.2.3 and 6.3.2.6; so I thought that using DESTDIR *was* doing things 'by the book'.
> 
 When we say "by the book" we usually mean by following the commands
on the page for that step (and ONLY those commands - you have
already shown a willingness to come up with your own version of the
grep command :-)  There are a number of different approaches to
package management, all of them have drawbacks.

 In my own case I "suppress" many of the static libraries, but that
restricts what I can do [ no statically-linked packages, some tests
in binutils fail, also I can't build sysvinit, tk, firefox [ with
system libs ], some of kde, or Linux-PAM without making a static lib
available (various different static libs).  So, although there are
some packages where I use --disable-static, in other cases I take
other measures (e.g. in flex) so that I can make a lib available when
needed.

 So, I'm not trying to condemn you for doing things differently.
I'm trying to point out what we mean by "follow the book".  Anything
which is different from the book runs the risk of putting you on a
less well-trodden patch.  It may be "fun" (in the sense of the word
used by operators and programmers) and very educational, but if
things break you get to keep both pieces.

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



More information about the lfs-support mailing list