<Sorry was on vacation just got back.>

comments inlined.......
I think Kumar Srinivasan would be the best person to answer if adding a 
$ORIGIN/../lib/<arch>
RPATH entry to jre/bin/java would be an issue or not.  I suspect it is not an 
issue.

But I'd recommend some well placed comments in the Makefile explaining the need 
if we do this.

-kto

On Jul 19, 2012, at 3:32 PM, Omair Majid wrote:

On 07/19/2012 01:54 PM, Kelly O'Hair wrote:
The java process does not need to have the runtime linker access
anything from there as far as I know.
Do you think anything might break if an RPATH to jre/lib/<arch>  was
added? I have done a custom build of OpenJDK7 with this change and it
seems to be working fine (haven't run extensive tests, though).

I ask because this seems like the easiest way to fix the JAWT breakage I
am seeing with OpenJDK7.

A little background:
JAWT (the AWT Native Interface) requires native libraries that are part
of a third party application to link with libjawt.so [1]:

"""
The final step ­ the most interesting one ­ is to write the native
rendering method, with an interface that conforms to the header file
that javah generated, and build it as a standard shared library (called
myRenderingLib in the above example) by linking it, for the Solaris
operating environment, against the jre/lib/sparc/libjawt.so library.
"""

Applications are not expected to invoke System.loadLibrary("jawt") to be
able to use jawt, but just rely on this linking.

Before the removal of LD_LIBRARY_PATH, the linker would find libjawt and
link the third-party native library with libjawt.so correctly. Now that
LD_LIBRARY_PATH is gone, the linker fails to link the file, which causes
those native libraries to fail to load.

Some programs using JAWT have had to modify code to work with this
change [2]; others remain broken.

I think the launcher will dlopen() something from jre/lib/amd64, and
I think all the libraries in the jre/lib/amd64 directory will have an
RPATH of $ORIGIN.
Yeah, that works for most native code in the JDK - either RPATH of
$ORIGIN is used by the library, or a System.loadLibrary() call from java
is used. JAWT seems like a special case where third-party native code
links against a library in the JDK. It cant use $ORIGIN, and hasn't used
System.loadLibrary() because it was never needed in the past.


The launcher main needs to link with libjli where all the launching really happens, once this is found, the launcher dlopens libjvm.so, which loads all the necessary and required classes
and libraries using System.loadLibrary.

There was no use-case which required me to add add lib/<arch>.

My suggestion is to see if System.loadLibrary can be used, this will bode well for the modularization effort. If this *must* be added to RPATH in which case, append this last
to ensure we don't break  anything.

Kumar


Thanks,
Omair

[1]
http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html
[2]
http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/trunk/LWJGL/src/java/org/lwjgl/LinuxSysImplementation.java?r1=3418&r2=3604

Reply via email to