On 07/29/2014 01:17 PM, Jiri Vanek wrote:
On 07/29/2014 01:05 PM, Florian Weimer wrote:
> As far as I can tell, currently, System.loadLibrary() is mostly
> unusable for Java libraries because
> they cannot influence the library search path. If you want to
> transparently load a DSO, you need to
> use System.load() and hard-code the path. This probably means
> patching upstream sources.
> Debian patches the default search path so that System.loadLibrary()
> searches /usr/lib/jni for DSOs
> with native code. This means that classes which call
> System.loadLibrary() just work, assuming that
> the Debian package installs its DSOs into /usr/lib/jni.
> Can we do something similar in Fedora? We probably want /usr/lib/jni
> and /usr/lib64/jni, for
> consistency with the rest of the system.
Then the most simple way is to provide symlinks in
from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../... ?
(Cc:ing the mailing list again.)
Is it a good idea to install files from RPMs through a symbolic link? I
suspect it's not, which would mean we'd have to use the upstream default
"/usr/java/packages/lib/amd64" in spec files (probably using a macro).
If that path is acceptable, it would be fine with me as well, but it
looks a bit ugly to me. It certainly has the advantage of being
compatible with both the proprietary JDKs and the Debian packaging
(which keeps this search path entry, it only adds /usr/lib/jni).
Florian Weimer / Red Hat Product Security