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
signature.asc
Description: Digital signature
