Need preliminary reviewers: Solaris/Linux shared library version changes
Long story, but the background may be important. It's not a slam dunk that
these changes will
go into JDK7, we may decide to do this in JDK8. I recognize it is late to be
doing this in JDK7.
If you have any experience with native shared library versioning or JNI usage,
I would really
appreciate you taking the time to look at this.
Background:
A while back, the JDK7 launchers were changed to NOT set LD_LIBRARY_PATH in
the
environment or use it in anyway to launch the jdk. This was and still is
considered a good
thing for us to have done. No applications should rely on LD_LIBRARY_PATH,
it's a
workaround mechanism and comes with some old baggage. But it comes with a
cost.
Low and behold, what we discovered was that a JDK6 process, if doing an exec
of a JDK7
launcher, or anything that might cause an exec of a JDK7, was leaving the
LD_LIBRARY_PATH
settings for JDK6 libraries in the environment for the JDK7 process to find.
And, low and behold, it found the JDK6 shared libraries in some cases.
So the JDK7 process would be running with a mix of JDK7 shared libraries and
JDK6 shared libraries.
This is considered a very very bad thing, but sometimes things appeared to
work, and
sometimes things would crash, missing newer extern symbols.
Workaround:
The workaround/solution has been to unset LD_LIBRARY_PATH in the appropriate
place, if you have
an appropriate place. The difficulty arises when LD_LIBRARY_PATH is being
used for some
other reason or tool, so just unsetting it needs to be done with care.
After running into a situation where the build utility ant (a popular Java
application)
was running JDK6, and after doing a build of some Java code with JDK7
crashed, I decided
to see what could be done to guarantee no mixing happened.
Goal/Approach:
My goal here is to prevent the mixing of JDK7 shared libraries with those of
other JDK releases.
My approach was to use shared library versioning to see I could group all the
JDK7 shared libraries
with the same version, a unique version for this release, and then have any
shared library dependencies
between them insist on that same shared library version.
Any mixing would trigger a runtime linker error.
Proposed Changes:
There are 2 webrevs here, one for hotspot and one for the jdk.
7021644: Consider using a new version name on all jdk7 shared libraries
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-jdk-mapfile/webrev/
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-hotspot-mapfile/webrev/
The libjvm.so and libjawt.so libraries will also provide the older version
name.
Mapfiles:
Sometimes called version scripts, do lots of things, or can, the only part of
the mapfiles
of interest here is the version name. When you link, the version names of the
shared
libraries used and seen at link time are baked into your executable or shared
library
so that at runtime, the runtime linker will make sure you run with the right
versions.
The error message may be a cryptic runtime linker error, but it will refuse
to run.
Issues:
* On the question of JNI usage, and user's JNI shared libraries being
dependent on the older
shared library version names from JDK6 and older. The JNI book references:
http://java.sun.com/docs/books/jni/html/invoke.html#4944
http://java.sun.com/docs/books/jni/html/invoke.html#24891
Implies that any explicit shared library dependencies on libjvm.so or
libjava.so would result
in a JNI shared library that is tied to that particular implementation.
It recommends using dynamic linking if multiple JDKs would be used.
My proposal does not impact dynamic linking, but could catch problems where
the dynamic
linking was done with LD_LIBRARY_PATH set to other JDKs.
It is an accepted fact that not everyone followed this advice, as good as
it was.
* Native apps linking directly to libjvm.so or any JDK shared library.
The JDK is not a native library interface provider, with a few exceptions,
libjawt.so and libjvm.so,
all the extern symbols in the JDK shared libraries are not public
interfaces.
Having said that, I'm sure there are some people who may have purposely or
accidently
become dependent on certain extern symbols in our libraries.
* Dynamic linking, which is usually the way most of our shared libraries get
loaded
into the process, is not an issue here. However, if the shared library has
a dependency on
another JDK7 shared library, that is where LD_LIBRARY_PATH could kick in
and cause
the wrong one to be loaded.
So you might think that the answer would be to dynamically link everything,
and in fact
that might be the direction we go with JDK8, that remains to be seen.
But that effort is much more work that this person was willing to do.
Please, if you read this far, please send me comments.
-kto
