RPATHS in binaries

[Kumar Srinivasan]

<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