Ken Moffat wrote: > On Mon, Mar 05, 2012 at 07:42:30PM -0800, Qrux wrote: >> You have to figure that most package maintainers have _also_ >> learned that same lesson; e.g., Perl devs realizing: "Oh, zlib >> _can_ have security implications, maybe use system zlib and stop >> embedding zlib so we don't have to track these problems. And, you >> also have to figure that even after having learned that lesson, >> some still choose to either embed or statically-link, because they >> see a good reason. > > We still have to patch perl-5.14 for a different vulnerability. I > repeat : if you know which static libraries have been linked by the > packages on your system, you can rebuild them if you ever have to fix > a vulnerability in a static lib. If you don't know, or don't care, > that's also fine by me - your system, your rules. > > Generally, you seem to have a lot of faith that package developers > know what they are doing AND consider security implications. My > experience is different - they usually know what they are doing, but > grasping the security implications of a library they have shipped as > a convenience is a different matter.
One thing I'd like to mention is that if you have a libx.a and a libx.so, the linker will use the .so file unless the developer has jumped through hoops to not use it. Yes, the package may have included code taken from a library and built directly into the package, but I think that's rare any more. That said, having both the .a and .so packages don't really give any advantage, but take up space on your disk. I guess an 'advantage' to static libraries is that applications can be distributed as binaries more easily, but that is out of scope for LFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
