3 ms·

> I've never gotten the hate for static linking I believe most of the dislike for static linking can be traced to a single incident: a really bad (as in "remot

by cesarb 8y ago

> I've never gotten the hate for static linking I believe most of the dislike for static linking can be traced to a single incident: a really bad (as in "remote code execution" bad) vulnerability in zlib, CVE-2002-0059. Back then, it was common to statically link to zlib (and zlib is a very popular library, the DEFLATE algorithm it implements being the "standard" compression algorithm), so instead of just replacing a single dynamic library and rebooting, everything had to be audited for the presence of embedded copies of zlib. Quoting from a message from a few years later (http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000055.html http://mail.openjdk.java.net/pipermail/build-dev/2007-May/00...): "[...] Updating the main system zlib package was easy, but finding all the embedded copies was a nightmare. I think we ended up grepping every binary and library in every package for symbols and other bits of code that looked like zlib. All the different versions involved compounded this. And when everything is found and patched and built and tested there's the cost of bandwidth to distribute all the extra stuff. So when people talk of removing static libraries they're talking about real costs -- time and money. After zlib there was a definite feeling of "never again"."

Hello71 8y ago
That's not a complaint about static linking though, that's a complaint about library embedding. Lots of Professional Enterprise Software as well as poorly designed games use a buttload of dynamic linking, but a few patches here and there and some API/ABI ignorance later, the libraries are impossible to replace.
TFortunato 8y ago
Unfortunately, this is conflating static linking with bad dependency management. ("Just copy it into your own repo", is a different step, that is unnecessary to do the second step, "and link it statically") There is no reason I see why you couldn't just have a build that produces the library .a file for zlib, which can then be pulled in as a dependency of your build / linked in statically. I totally agree, they had a nightmare situation on their hands, but I don't think static linking was solely to blame :-)
- tedunangst 8y ago
  I have 100s of binaries on my system. Which ones do I need relink?
  - juliangoldsmith 8y ago
    You can write a script to look at package files' makedepends, and rebuild everything that uses the offending library.

by cesarb 8y ago

Hello71 8y ago

That's not a complaint about static linking though, that's a complaint about library embedding. Lots of Professional Enterprise Software as well as poorly designed games use a buttload of dynamic linking, but a few patches here and there and some API/ABI ignorance later, the libraries are impossible to replace.

TFortunato 8y ago

Unfortunately, this is conflating static linking with bad dependency management. ("Just copy it into your own repo", is a different step, that is unnecessary to do the second step, "and link it statically") There is no reason I see why you couldn't just have a build that produces the library .a file for zlib, which can then be pulled in as a dependency of your build / linked in statically. I totally agree, they had a nightmare situation on their hands, but I don't think static linking was solely to blame :-)

tedunangst 8y ago
I have 100s of binaries on my system. Which ones do I need relink?
- juliangoldsmith 8y ago
  You can write a script to look at package files' makedepends, and rebuild everything that uses the offending library.