By investigating some JNI libraries, I made a `ldd /usr/lib64/icedtea8/jre/lib/amd64/libjawt.so`, which was failing to found some needed libraries, objdump'ing it gives a RUNPATH of $ORIGIN (sic), as the other libraries installed by icedtea; for a quick test, `qlist icedtea | grep -F .so | xargs objdump -x | grep RUNPATH`. That also means (if I'm correct) that you can't use any of theses libraries wihout specifing yourself which to load and where to load (which doesn't seems to be an issue for icedtea but is one for something linking to any of these, such as when using the JNI).
This is not a bug, but a deliberate means to allow OpenJDK to find its libraries without them being on the linker path. $ORIGIN is a placeholder for the directory where libjawt.so is located. It allows the other libraries to be located relative to its installed location. The test you mention actually shows the expanded values: RUNPATH $ORIGIN:/usr/lib64/icedtea7/jre/lib/amd64:$ORIGIN/jli:/usr/lib64/icedtea7/jre/lib/amd64/jli The runpath here is $ORIGIN:$ORIGIN/jli which expands to /usr/lib64/icedtea7/jre/lib/amd64:/usr/lib64/icedtea7/jre/lib/amd64/jli As you can have multiple JVMs installed, you don't want libjvm.so to be found by the linker cache maintained by /etc/ld.so.conf. These RUNPATH values are also present in the binaries (which are JNI programs themselves), so they can find their libraries without the linker cache. e.g. for java: RUNPATH $ORIGIN/../lib/amd64/jli:$ORIGIN/../lib/amd64
