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@xxxxxxxxxxxxx>: > > > 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.
