RPATHS in binaries
kelly.ohair at oracle.com
Fri Jul 20 02:58:52 UTC 2012
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.
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 :
> 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 ; 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.
More information about the build-dev