[PATCH] Allow usage of external zlib copy

Gary Benson gbenson at redhat.com
Mon May 14 12:11:50 UTC 2007

Phil Race wrote:
> A libjpeg has been baked into JDK since 1.0 I really don't think
> I want to change that now.  I just don't see the value.  Instead
> I see a lot of churn

For distributions the value of not having static copies of libraries
shows itself when security issues arise.  And coincidentally the best
example I of this was a zlib issue.  The zlib manual used to say
something like "the best way to use zlib is to import a copy into your
program sources and build it statically" -- so *everybody* did.  And
then someone found an exploitable double-free in zlib, CVE-2002-0059.
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".

Having said that I've also been involved in distributing binaries that
had to pre-built for different operating systems, and I know there's a
great deal of value in simplifying the number of variables you have to
deal with.  I think the solution here has to be something that allows
Sun to continue distributing statically linked stuff while allowing
distributions to dynamically link.  Even if we can't upstream the
libjpeg changes, I'm sure most distributions would prefer shipping an
"unofficial", patched version of libjpeg to shipping two copies.


More information about the build-dev mailing list