Some of you will have noticed that I'm commenting about how to
prevent static libraries being built when I make updates - at least,
where it is feasible - suppressing static libs for other packages
such as cdparanoia will best be covered in the wiki ("let it
install, then rip them out"). If you don't care about maintaining
your system after you've built it, you don't need to read this.
Perhaps you are wondering why I think it is important to get these
pesky .a files under control ? Here are my current thoughts and
findings, based on my latest 6.4 build (I haven't attempted any of
kde4 yet, but from memory static libs are not a big deal there).
So, why do I care about them ?
I did think about posting under the inflammatory label "static
libraries considered harmful", but they are not an intrinsically bad
thing. They are easier to create than shared libs - just put some
utility functions into an archive, and when you link it the ones you
used will be pulled into the executable. If a vulnerability is
found, the whole package gets updated.
Now, compare static libraries which are intended to be used by
unrelated programs (libz.a has to be the example, because of the
pain it has caused in the past). You update libz, but what about
all the packages compiled against the old static libz.a ? Do you
like reading your build logs ? Do you even have build logs ? For
shared libraries, the usual process is to just install the new
version, and its users will find it at runtime.
If you are going to be hacking on the code of a package, it makes
sense for you to build static libs that will be used by that
package. Similarly if you need the library in a recovery situation
(e.g. you might want a statically-linked shell).
When I first started using LFS and BLFS for my dekstop, I didn't
install very much, compilers were less slow, and it wasn't too much
of a big deal to just rebuild the system after a vulnerability.
Nowadays, I've got several systems available to me (multiple
machines, each with older and newer installs). Plus, I now find I'm
keeping systems in use for longer, sometimes more than a year (with
necessary updates and newer kernels), and I have other interests.
Rebuilding takes time I would prefer to use for other things.
And then there is the educational aspect - as you focus on static
libs, you learn a bit more about how it all fits together (well, I
did, maybe some of you guys already know it).
Isn't this essentially an LFS problem (rather than BLFS) ?
Some of it belongs in LFS, much of the detail is for BLFS, and I
see no reason to make my future maintenance of the system harder by
creating unnecessary static libraries in BLFS.
The big problem is still that any vulnerability in the toolchain
will require us to rebuild the whole system (gcc uses
libc_nonshared.a, I think libgcc.a gets compiled in to programs -
for the moment I haven't touched toolchain libs other than to 'hide'
libbsd-compat.a and libiberty.a. At the moment I'm treating gmp and
mpfr as parts of the toolchain. I hope to look at them on my next
build.
If LFS goes in for package management, that implies people will be
encouraged to update their existing systems. They will need to know
what needs to be recompiled because of its static linkages.
For the moment, my method isn't adequately dealing with everything
in LFS - I need to take action for libperl (even though its users
are in BLFS), and get more detail on which of the toolchain static
libs actually get used. Taming these files is a long task, the BLFS
part of it is now reaching a stage where I have some results.
So, what am I doing in my builds ?
I'm still fine-tuning a 'sweep' function in my build scripts to
move static libs from .a to .a.hidden. The script works reliably,
but it's a bit noisy and needs more work to stop it reporting false
positives in the logs. This means that the static libraries I might
need are not immediately available, but they reappear if I rename
them back. Occasionally there might be a runtime problem that I
haven't yet noticed, but more commonly either configure or make will
barf and I can add another package using a static lib to the list.
This only alters libs in /usr/lib (find ... -maxdepth 1). It
ignores known toolchain libs for the moment.
Similarly, I took the opportunity to get rid of libtool's .la files
while I was doing this, because they shouldn't be needed (we have
shared libraries). Interesting. Did you know that openjade
requires libosp.la, even though the only libraries referenced in
there are libosp.so libpthread and libnsl ?
Unfortunately, I overlooked that the xulrunner static libs
(including nss, nspr in my current build) are in a subdirectory,
so I don't actually know what used them, or which of them were
needed.
OK, what have I learned about the users of static libs ?
In LFS, module-init-tools uses libz.a. This seems reasonable.
I found nothing else using static libs (other than toolchain libs).
I failed to spot that libperl.a is installed several levels down.
A quick grep through my logs suggests that only rxvt-unicode and
gnumeric are using it (from the packages that I build). So,
another 2 to rebuild if there is a perl vulnerability.
Tcl and tk create libtclstub / libtkstub (tk is from memory, I've
stopped building it) and these are used by anything which links to
them (even sqlite, if tcl is present).
Tangentially, nss appears to be using its own version of libz. I
thought I'd cracked that in a build with separate nss and nspr, but
I can't find my testing notes and recent examination with ldd failed
to find them using the system zlib.
Nss (or whatever part of mozilla you use to provide nss) creates
inter-alia libcrmf.a. From this run, I don't have reliable results
to show what used that.
Libbonobo needs libname-server-2.a from ORBit2. Interestingly,
that file is installed even when ORBit2 is built with
--disable-static.
And that's all. I don't have many old packages, nor do I build
large parts of the modern desktop experience, so I'm sure there are
other packages that need static libs. I've been trying to get the
.a files under control for a while now, so forcing new packages to
be built with shared libs is my normal process.
ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
