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-18.104.22.168-22.214.171.124.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. ***