heiko at zuerker.org
Mon Jan 10 11:13:24 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
>> > need to be statically linked. --with-pic might help when
>> > 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
>> > upgrade, or openssl, etc. I don't know if it would annoy people if
>> > 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
> 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.
The more I think about it, the better I like the idea.
>> 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.
That's a good point.
> 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
> 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
> 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.
In cases like this,I would just delete the file manually.
More information about the hlfs-dev