[lfs-dev] More on static libs

Bruce Dubbs bruce.dubbs at gmail.com
Thu Mar 12 14:19:36 PDT 2015

Ken Moffat wrote:
> On Wed, Mar 11, 2015 at 08:13:02PM -0500, Bruce Dubbs wrote:
>> 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
> scripts).
> 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
> them.

I've thought a little more about this.  What do you think about adding this to
6.73. Cleaning Up:

mkdir -p /usr/lib/static
mv -v /usr/lib/*.a /usr/lib/static
mv -v /usr/lib/static/lib{a,b,c,etc}.a /usr/lib

In other words, put all the static libs in a location not normally searched and 
then move back only those really needed.

I could write a paragraph explaining the core issues and point to a fuller 
explanation in BLFS.  This solves a couple of issues:

* Explain without having to add a whole new section
* Not having to change a lot of packages
* Don't affect regression tests
* It is optional

The only downside is that if a use re-installs a package, the process needs to 
be repeated.

We could potentially fix that issue by creating a minimal script to do this that 
could be run at any time, but I think that would best be left as an exercise for 
the user.

   -- Bruce

More information about the lfs-dev mailing list