Does OpenJDK statically link the C++ runtime?

[Dr Andrew John Hughes]

On 20:43 Wed 04 Jan     , John Von Seggern wrote:
> Kelly,
> Thanks for taking the time to answer my question.  This information is
> very helpful.
> 
> > So in general, doing static linking is a bad idea and should not be done lightly, if ever.
> 

The most obvious issue for me is security.  If a security flaw appears in libstdc++
(or whatever library is linked statically), you have to rebuild to fix it.  So the JDK
has to have a security update due to one of its dependencies.

> As I've been looking into these issues, I've encountered developers
> who advise against dynamically loading any C++ code.  For example, a
> coworker referred me to this article:
> 
> http://www.trilithium.com/johan/2005/06/static-libstdc/
> 
> If you don't want to do all that reading, the key quotes are:
> 
> 1. "C++ ABI changes have been introduced with every major release of GCC"
> 2. "code compiled against different ABIs is simply not binary compatible."
> 3. "a fairly workable compromise is to link all C++ code into an
> executable while using dynamically loaded C libraries only."
> 4. "for this to work reliably you must not use dynamically loaded C++ code"
> 
> As I understand it, Sun took a similar approach for JDK4.
> 

A lot of this depends on development model.

In a FOSS model, the source is available so anyone can perform a rebuild.  Hence,
if they upgrade their compiler, they can simply rebuild its dependencies.  GNU/Linux
is provided in distributions which means that each part of the stack is under the control
of the same entity.  So they know if a gcc upgrade is performed and to do a mass
rebuild of all packages (usually for a new release).  This also shakes out build problems
with that new compiler.  A lot of the work IcedTea (http://icedtea.classpath.org/) has
done with OpenJDK relates to making it work well in this kind of environment.

In a proprietary model, which OpenJDK's build system is designed around, the user is
provided with a blob and has to cross their fingers that it runs.  If it doesn't, all
they can do is go back to the provider and complain.  Hence, it is in the provider's
interest to make that blob compatible with as many systems as possible.  This is done
by statically linking libraries and is also the reason you'll find copies of system
libraries (libpng, libjpeg, zlib, lcms) in the OpenJDK tree as well as libraries like
Gtk+ (for the look and feel) being opened dynamically.  The aim of all that is to
minimise dependencies and make the binary self-contained, but it means that if any
part of the stack has a security issue, a rebuild is necessary.  Such a blob is always
going to be safer in terms of compatibility as all the parts are in the same box.
This is the model followed by applications on Windows and Mac OS platforms, and
leads to issues such as "DLL hell" with dynamically linked bundled libraries, as several
applications all bring their own copies of the same library but different versions.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120105/2c1c5cbe/signature.asc>