[lfs-dev] static libs: libc_nonshared.a and also gcc tests

Ken Moffat zarniwhoop at ntlworld.com
Sat Mar 14 13:55:42 PDT 2015


On Sat, Mar 14, 2015 at 11:12:20AM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> >Posting this under a slightly different title, to start a separate
> >thread.
> >
> >1. For libc_nonshared.a I have concluded that it is not worth the
> >testing effort to keep it out of the normal search path.  In other
> >words. I keep it at /usr/lib/libc_nonshared.a : as well as the
> >book's sanity test, I had failures in linking the static libz.a, and
> >then I got  "C compiler cannot create executables" in one of the
> >next configure scripts.  For me, in the light of what Bruce pointed
> >out about current libc.so being an ld script, I have concluded that
> >it will be a waste of time, and fragile, to find exactly which
> >packages/tests need this.
> >
> >2. With that file available, my i686 gcc/g++ tests had failures in
> >pr59063-2.c (gcc,g++) and pr61160-3.c (g++).  On a completed system,
> >copying the tests and linking with -L, -Wl,--verbose just works (the
> >shared libs are found), but creating static executables seems to
> >need libc.a for gcc, and libstdc++.a and libm.a for g++.  At the
> >moment, this is untested - I will start a build shortly, and pick up
> >what Bruce reported for the binutils tests.
> >
 Point 2 for gcc is NOT looking good, in fact on the first attempt (install
failed because libpthread_nonshared.a was still needed at that
point) the g++ and libstdc++ tests failed catastrophically.  Oh, and
libstdc++.a comes from this package.  Looking at some of the tests
outside of chroot, when I try to link them statically the only new
things missining are libstdc++, libgcc.a, libgcc_eh.a which all come
from gcc.  I also had a few failures in binutils.
> 
> Figuring this out is good knowledge, but many of our users do run tests in
> BLFS.  Personally, I run tests when doing an upgrade for the book and assume
> that other editors also do that.  When doing a check, like during the
> package freeze before release where I'm building most of the packages in the
> book, I do not generally run the tests.

Yes, I do the same for an upgrade, but for that I do not have a
script.
> 
> My impression is that most of the issues where tests want to use static
> libraries actually are in the tests run by the basic packages of LFS,
> especially binutils and gcc.  Packages in BLFS Chapter 13 are also
> candidates.  However we really won't know for sure until each package is
> tested.
> 
> In any case, I don't want to complicate LFS/BLFS by doing a lot of moving
> packages or specifying -L /usr/lib/some-special-dir-with-static-libraries
> more than a very few times.  I can see it for libz.a, but not for important
> gcc or glibc static libs.
> 
>   -- Bruce
> 

I'm still reforming/revising my view of what is needed in-general.
It might be some time before I post again on this thread.

ĸen
-- 
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