Does OpenJDK statically link the C++ runtime?

John Von Seggern vonseg at gmail.com
Thu Jan 5 01:43:10 UTC 2012


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.

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.

The blog article and JDK4 are both getting pretty old now, and it
sounds like maybe the situation has changed since then.

> It is quite possible that we don't need to static link anything anymore, but that would need to be verified.

What has changed since JDK4?

> When you distribute a C++ application you always need to worry about compatibility issues.

Do you know of a general approach that addresses these issues?

Feel free to ignore me if answering these questions would take up too
much of your time.  I'm mainly just asking now because I'd like to
know more.  (For my application, I can use the file system rather than
JNI.  JNI would have been more efficient, but this part won't be the
bottle-neck anyway.)

Thanks again,
-John

On Wed, Jan 4, 2012 at 5:15 PM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
>
> On Jan 3, 2012, at 10:16 PM, John Von Seggern wrote:
>
> Does OpenJDK continue to take this approach?
>
>
> Depends on who does the build. The default might be to statically link,
> pretty sure anyway.
>
> I'm asking because I would like to use the Java Native Interface to
> call functions in a C++ library (that statically links the C++
> runtime).  When I distribute my application, do I need to worry about
> C++ ABI compatibility issues?
>
>
> When you distribute a C++ application you always need to worry
> about compatibility issues.
>
> If you statically link in a C++ library, you need to make sure you are not
> also providing those
> interfaces as your own public exported interfaces, if you use the proper
> version scripts (mapfiles) this
> kind of thing can work fine. But it means that you have baked in the
> implementation of code that
> you don't maintain, and any bugs in that code requires you to rebuild your
> product and re-ship.
> There is a maintenance cost to static linking.
>
> So in general, doing static linking is a bad idea and should not be done
> lightly, if ever.
>
> On Solaris, in OpenJDK makefiles, there is no static linking, or shouldn't
> be any.
>
> On Windows, we do static linking of some DLLs, but not the primary one
> MSVCR100.DLL,
> except in rare cases, which I try to burn from my memory every time I see
> them,
> and we have lots of debates on that issue. With Windows you have to ship the
> MSVC*.DLLs with your product, so there are space considerations, big DLLs
> here.
>
> On Linux, we shouldn't use static linking, but we had to a long time ago,
> and we just haven't undone
> it completely. Obviously the distros don't want static linking, but when
> Oracle builds a Linux
> distribution, the binaries need to run on a variety of Linux systems, so we
> need to be careful, and
> we don't want to build a separate Oracle JDK for every Linux distro.
> It is quite possible that we don't need to static link anything anymore, but
> that would need to be verified.
> When the initial JDK4 work was done on Linux, static links of the C++
> runtime was the only way
> for us to create binaries that had any chance of running on a variety of
> distributions of Linux.
>
> Of course, then there is the other sharing issue, the one where you copy the
> source into your
> repository and build your own private version of a library that also ships
> with the underlying system.
> That's another story.
>
> -kto
>
>
>



More information about the build-dev mailing list