On Thursday February 12 2009 04:44:15 pm Dan Nicholson wrote: > The reason why it's recommended to static link libssl is because the > developer's have a terrible habit of changing the API frequently. > Static linking avoids API breakage. But if you're going to rebuild ssh > when you update libssl anyway, then that advantage is gone. You might > as well just use the DSO. > > -- > Dan
I have 54 programs in /usr/bin linked to libssl.so. I often have irssi, ssh, and wget, using ssl at the same time, for long periods of time. Statically linked, and stripped, is probably 200K of memory each, just for duplicate copies of libssl.a in memory. I have system memory coming out of my ears, but it's still not efficient. If this made sense, then we should do it with everything. As for api changes, we have exactly the same problem with any library upgrade. If a bug in ncurses is found (just for example), and they decide to add the fix to a new release instead of offering a patch (like openssl does), then we're in big trouble if the api changed, and need to recompile every packaged linked to it. This is what distributions have to deal with, and I don't think it can be avoided. libiberty is only offered as a static library because they like to make changes without regard for backwards compatibility. I think in our projects none of us upgrades the toolchain without also rebuilding the entire system (many distributions don't do this), so for us a shared version of libiberty should be usable. Although, this doesn't really save system memory unless you do parallel builds, and even then is a very small improvement, but in principal it works. This probably won't go anywhere, but I think it's worth talking about. We're trying to balance convenience, security, usability, and efficiency. robert
pgpYSoGwCke2p.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
