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.
--
[]s,
Fernando
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
