[lfs-dev] More on static libs

Fernando de Oliveira famobr at yahoo.com.br
Thu Mar 12 14:39:46 PDT 2015

On 12-03-2015 18:19, Bruce Dubbs wrote:
> 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 didn't remember receiving this post.

> 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 am doing similar, when cannot remove in the config. But I do compress
them with xz, first.

> 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.

I think that the ones that could be disabled in configure sould be
treated differently: just not installed.


More information about the lfs-dev mailing list