Need preliminary reviewers: Solaris/Linux shared library version changes

[David Holmes]

Hi Kelly,

On the Hotspot side this change would appear to bake in the version info 
at build time. So when I build Hotspot I will either build for JDK6 or 
JDK7 or ... and then I wont be able to drop the VM libs I just built 
into a different version of the JDK - is that right? If so I'd want a 
way to disable the version checking during development so that I can 
still drop the VM into different JDK versions.

David

Kelly O'Hair said the following on 03/17/11 11:59:
> 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
>