[lfs-dev] More on static libs

Ken Moffat zarniwhoop at ntlworld.com
Wed Mar 11 20:22:33 PDT 2015

On Wed, Mar 11, 2015 at 08:13:02PM -0500, Bruce Dubbs wrote:
> I've been working with static libraries today.
> I was able to remove most of them and got through a complete LFS build.
> What was left was:
> bzip2:/usr/lib/libbz2.a
> gcc:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/libgcc.a
> gcc:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/libgcc_eh.a
> gcc:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/libgcov.a
> glibc:/usr/lib/libc.a
> glibc:/usr/lib/libc_nonshared.a
> glibc:/usr/lib/libcrypt.a
> glibc:/usr/lib/libdl.a
> glibc:/usr/lib/libg.a
> glibc:/usr/lib/libieee.a
> glibc:/usr/lib/libm.a
> glibc:/usr/lib/libmcheck.a
> glibc:/usr/lib/libpthread.a
> glibc:/usr/lib/libpthread_nonshared.a
> glibc:/usr/lib/librpcsvc.a

I think it was Armin who pointed out that Arch do not remove
toolchain static libs.  I remove some of them, but the above *glibc*
libs seem to do no harm.  But /usr/lib/gcc/ - why would we care ?
The problem is static libs in the normal place (i.e. /usr/lib) which
may get accidentally linked in if the shared lib was botched.

For libbz2.a, I think I said that I attack it because an x86_64
build attempted to use it when I broke a version upgrade : i686
would have quietly linked in the static non-pic, which was why I
dispose of it in the package.
> However, some additional tests failed.  The *new* failures are:
> 078-binutils-2.25:FAIL: static preinit array
> 078-binutils-2.25:FAIL: static init array
> 078-binutils-2.25:FAIL: static fini array
> 078-binutils-2.25:FAIL: static init array mixed
> 078-binutils-2.25:FAIL: Could not link a static executable
> 078-binutils-2.25:FAIL: Run mpx1 with -static
> 078-binutils-2.25:FAIL: Run mpx2 with -static

I do not recognize the mpx tests, but I mentioned the other 5
earlier, probably libz.a is needed for these to pass.
> 103-libtool-2.4.6: 70: Runpath in libtool library files    FAILED
> 103-libtool-2.4.6:117: enforced lib prefix                 FAILED
> 103-libtool-2.4.6:170: Run tests with low max_cmd_len      FAILED

New to me, but then I had a static libltdl.a.  For libtool and the
other lib which I queried (libcap?), we appear to be doing something
different but I have not identified my error at the moment (I
haven't looked since the weekend).
> 110-automake-1.15:FAIL: t/lex-clean-cxx.sh
> 110-automake-1.15:FAIL: t/lex-depend-cxx.sh

The static libfl.a, I think.
> I'm having second thoughts about removing the static libraries.  There are
> really not that many in LFS and some in glibc appear to really be needed.
> I'm not sure if the gcc libraries above are needed or not.

Partly, it is a question of *policy*.  Most of our users will not
want general static libs (the days of building static packages to
rescue your system if you broke it are, I hope, long gone).  But a
few users might want static libs, and perhaps not just for gcc/glibc
(it seems very likely that those two might be used in configure

This is why I move static libs that I am uncertain about to new
names (currently, {,.hidden}.  After past problems with libtool in
obscure cases, certainly on ppc or ppc64 when I was still building
on that, but I think also on x86_64 at some time, I still do the same
for .la files, but ISTR you/we ("tne books") already remove most of

A look at one of Fernando's posts in another thread suggested he
moves them to a separate directory.
> OTOH, Ubuntu 14.04.2 has none of the above libraries in a standard install.
> Is removing static libaries really worthwhile?  I'm leaning to no.  It takes
> away options from the user that would be hard to replace without rebuilding
> the entire system.

Going by what ubuntu does merely indicates that they are not needed
in a standard install.  I've no idea what ubuntu does for testing
before it ships updated packages, but I have noted that some other
distros do not normally run 'make check' (for BLFS I'm normally in
that situation myself, with one or two exceptions).

For me, I already delete a few, having ascertained that none of my
current applications need them.  And yes, I did once have to rebuild
an LFS package, back when I was building full gnome-3 : I think it
was for gdm or one of its deps such as PAM - but it was a quick
rebuild.  At the weekend when we were first discussing this, I
thought about mentioning the need to sometimes keep static libs
available, but could not come up with suitable wording.

The main point is to avoid accidentally linking static libs from a
different package into a package - the old zlib issue.  There is
nothing intrinsically wrong with static libs, the problem is only
when you do not know that a static version of a lib (which is now
being upgraded or fixed) has been used.  And it is sometimes
convenient to be able to reinstate some of them.  My scripts have
their own 'functions' module which allows me to do things like
identify the directory name, measure directory space, log what got
installed, etc.  And as part of that I "sweep any .a files under the
carpet" at the end of each package (by renaming them).

Full disclosure: I reinstate the static libs I have mentioned
(libfl, libz) before running configure on the packages where they
are used in tests, I supposed I really ought to do that after
'make', and remove them again before 'make install' : I'm obviously
too trusting that they only get used in the tests ;-)

My method is particularly convenient when I add a new tcl/tk package,
or a new kde package which needs the (one) static lib - usually, I
build it manually the first time, and notice that it needs a static
lib, so by the time I script it I can temporarily reinstate that
lib.  The mozilla stack used to be similar (libcrmf.a) - at one time
I copied a routine from Andy which converted it to a .so (dangerous,
it is unversioned) but I think I no longer do that.

Summary: overall, avoiding the accidental inclusion of static libs
(e.g. when the build breaks because the builder did something wrong)
is important in knowing what needs to be rebuilt if a package is
later found to be vulnerable.

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