Currently libjvm.so and libjava.so are not mentioned in /etc/ld.so.conf.d. Therefore it is not possible to write software which has to link against these libraries without using rpath or dlopen. This blocks packages like python-jcc from entering Fedora (bug 449360). See http://thread.gmane.org/gmane.linux.redhat.fedora.devel/85542 for a discussion of these topics on fedora-devel.
Hi, any news here? It blocks a python module ;)
Some alternatives magic may be needed in addition to making it appear in ld.so.conf.d Assigning to Jiri to investigate.
This is still a problem. I was just pointed to the `mesos` package. This needs to link against a libjvm.so. Currently it does: $ readelf --dynamic ./usr/lib64/libmesos-0.18.0.so.0 | grep jvm 0x0000000000000001 (NEEDED) Shared library: [libjvm.so] 0x000000000000000f (RPATH) Library rpath: [/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.6.pre02.fc21.x86_64/jre/lib/amd64/server] So it hardcodes a path that will change on updates. And it will always use openjdk 7. Also, yum only see the dependency on libjvm.so and selects java-1.8.0-openjdk (!) to provide that dependency. For some reason java-1.7.0-openjdk does not provide 'libjvm.so' (but it does provide 'libjvm.so()(64bits)'.
Fedora allows installation of multiple JVMs, which are selectable by various configuration files (/etc/java.conf, ~/.java/java.conf, per-application config files, ...). Applications shouldn't link directly to default libjvm.so, but rather link dynamically to libjvm.so loaded from configured $JAVA_HOME. dlopen() is the right way to go.
The problem is the libjvm.so does not reside in $JAVA_HOME. It lives somewhere deep in the directory tree and the exact location differs for each JDK version and platform.
Moving this to the current version of OpenJDK.
*** Bug 740762 has been marked as a duplicate of this bug. ***