On Mon, 2010-02-01 at 14:59 +0100, Heiko Baums wrote:
Am Mon, 01 Feb 2010 22:58:24 +1000 schrieb Allan McRae <allan@archlinux.org>:
I disagree. Static libraries generally suck and hide rebuilds needed for security issues. So unless something specifically needs the static library, I think it should be removed.
Such rebuilds are only hidden if a program is linked statically against a library even if it can be linked dynamically, which should be avoided anyway. If a program is linked dynamically it doesn't touch the static library.
If a program is built static against an insecure library, upgrading the insecure library means the static binary is still vulnerable. That's what Allan means.
So if a dev, TU or AUR maintainer builds a package which depends on a library. This package should usually be linked dynamically against this library. In this case the static library isn't needed. But if such a package like fbsplash needs to be statically linked against a library it's only possible if the static version is available.
When we switch to glibc-based initramfs, there shouldn't be any need for static compiled binaries anymore, ever.
And other people who probably just want to write software for their own, who want to build a portable app or to learn programming or whatever and want or need to use statical linking can't do this without the static libraries.
Static binaries are everything but portable. Static linking to glibc can freak out when you're using nss_* libraries for uid and gid resolving.
And do you want everybody who needs the static version of a library for whatever reason to file a bug report for every single case and to explain why he needs this static version?
No, they shouldn't need those libraries.
That would take too much time while building a static library doesn't take much more time and disk space.
Static libraries are bad. Besides taking up diskspace, they're just bad to use. Ulrich Drepper has a nice PDF about this.