robert at linuxfromscratch.org
Mon Jan 10 10:50:18 PST 2005
On January 9, 2005 07:27 pm, Ken Moffat wrote:
> On Sun, 9 Jan 2005, Robert Connolly wrote:
> > Almost everything is dynamically linked by default. insmod, and ldconfig,
> > need to be statically linked. --with-pic might help when vulnerabilities
> > are found. If you don't have a static version of zlib then you
> > automatically know that you won't have to rebuild other applications to
> > upgrade, or openssl, etc. I don't know if it would annoy people if static
> > libs were missing.
> With the possible exception of libc (to build a static toolchain), I
> had assumed that removing static libs was a good thing for this very
> reason. Even on a development box, most of us won't miss static libs.
It wouldn't bother me to start getting rid of the static libs. I bet we can
get away with just having libc.a, and libgcc*.a. libmath doesn't have a
static version. Only having shared libraries would match well with the
pic/pie toolchain too.
> Of course, Bennett will take a different view, but then he'll
> have already documented what he has to rebuild if package foo has a
> vulnerability :) What gets me, at least on the desktop, is the number
> of static libraries scattered around (e.g. by almost anything in gnome).
Building everything statically linked is a specialty task anyway.
On my 0.1 box:
$ find /usr/lib -type f -name "*.a" | wc -l
It's 143 on my desktop with kde.
My idea of having coreutils, bash, etc, optionally statically linked was maybe
not so great. My reasoning was that things would still work if libc.so was
damaged, but if a statically linked /bin/bash, or /sbin/init, were damaged we
would have the same problem.
ncurses doesn't support '--with-pic', but it does use '--without-normal
--with-shared' which installs shared libs and not static ones, except for
libncurses++.a for some reason.
More information about the hlfs-dev