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