Need preliminary reviewers: Solaris/Linux shared library version changes

[Kelly O'Hair]

The logic in the hotspot makefiles that plops the hotspot just built into a copy of the BOOTDIR jdk
(normally a jdk6 image) and expects that to run has always been an issue to me.
In general, each JDK release changes compilers and potentially C++ runtimes, in my opinion, it is never
guaranteed that you can just insert a hotspot built for one jdk release into another.
It might work, it might not. Having said that, it should continue to work as it has.

The JDK6 shared libraries will be looking for SUNWprivate_1.1, and I tried to allow for that by having
SUNWprivate_1.1 defined as:
  SUNWprivate_1.1 { } HOTSPOT_SHARED_LIBRARY_VERSION;
so it should work. But I'll need to experiment some on this to make sure.

-kto


On Mar 16, 2011, at 7:22 PM, David Holmes wrote:

> 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