RPATHS in binaries
omajid at redhat.com
Thu Jul 19 15:32:54 PDT 2012
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