On 07/29/2014 06:18 PM, David Walluck wrote:
On 07/29/2014 11:34 AM, Omair Majid wrote:
If it helps, changes we manage to push into OpenJDK should show up
sooner or later in proprietary JDKs. That said, I agree, a scheme that
makes it harder to use proprietary JDKs would undo a lot of work Fedora
(and JPackage) have put into the Java packaging guidelines.
I have to admit, I am really not following the proposed change here nor
the reason for it.
I can say that the reason for moving the jni libdir is that libraries in
%{_libdir} are dynamically linked vs. dlopened like JNI libs are.
Otherwise, %{_jnidir} has always been %{_prefix}/lib/java (even on
64-bit) as it was created before multiarch support. After which, I
believe certain Linux distros may have changed it to %{_libdir}/java,
but on Fedora it seems to be %{_prefix}/lib/java.
As far as I understand it, you are not allowed to place DSOs in
%{_jnidir}, you have to use %{_jnidir}/%{name} instead. So adding
%{_jnidir} to the default search path will not help at all.
In reality, both approaches exist:
/usr/lib/java/cvc4/libcvc4jni.so
/usr/lib/java/cvc4/libcvc4jni.so.2
/usr/lib/java/cvc4/libcvc4jni.so.2.0.0
/usr/lib/java/gdal/libgdalconstjni.so
/usr/lib/java/gdal/libgdalconstjni.so.1
/usr/lib/java/gdal/libgdalconstjni.so.1.16.2
/usr/lib/java/gdal/libgdalconstjni.so.1.17.1
/usr/lib/java/gdal/libgdalconstjni.so.1.18.0
/usr/lib/java/gdal/libgdaljni.so
/usr/lib/java/gdal/libgdaljni.so.1
/usr/lib/java/gdal/libgdaljni.so.1.16.2
/usr/lib/java/gdal/libgdaljni.so.1.17.1
/usr/lib/java/gdal/libgdaljni.so.1.18.0
/usr/lib/java/gdal/libogrjni.so
/usr/lib/java/gdal/libogrjni.so.1
/usr/lib/java/gdal/libogrjni.so.1.16.2
/usr/lib/java/gdal/libogrjni.so.1.17.1
/usr/lib/java/gdal/libogrjni.so.1.18.0
/usr/lib/java/gdal/libosrjni.so
/usr/lib/java/gdal/libosrjni.so.1
/usr/lib/java/gdal/libosrjni.so.1.16.2
/usr/lib/java/gdal/libosrjni.so.1.17.1
/usr/lib/java/gdal/libosrjni.so.1.18.0
/usr/lib/java/libjnilasso.so
(This is the complete list for the current Fedoras, unless I botched
something.)
But as there is no benefit from using the prescribed directories, the
libraries are scattered all over the place:
/usr/lib/accumulo/libaccumulo.so
/usr/lib/arc/libjarc.so
/usr/lib/bluecove/2.1.1-SNAPSHOT/libbluecove.so
/usr/lib/bluecove/2.1.1-SNAPSHOT/libbluecove_arm.so
/usr/lib/bluecove/2.1.1-SNAPSHOT/libbluecovez.so
/usr/lib/bluecove/2.1.1-SNAPSHOT/libbluecovez_arm.so
/usr/lib/bolzplatz2006/libirrlicht_wrap.so
/usr/lib/bolzplatz2006/liblwjgl.so
/usr/lib/brltty/libbrlapi_java.so
/usr/lib/cvc3/libcvc3jni.so.5.0.0
/usr/lib/eclipse/plugins/org.eclipse.core.filesystem.linux.arm_1.4.100.v20140325-0646/os/linux/arm/libunixfile_1_0_0.so
…
/usr/lib/vtk/libvtkViewsInfovisJava.so
/usr/lib/vtk/libvtkViewsJava.so.5.10.1
/usr/lib/vtk/libvtkVolumeRenderingJava.so.5.10.1
/usr/lib/vtk/libvtkWidgetsJava.so.5.10.1
/usr/lib/zorba-java/libzorba_api.so
/usr/lib/zorba-java/libzorba_api_java.so
/usr/lib64/accumulo/libaccumulo.so
/usr/lib64/arc/libjarc.so
/usr/lib64/bluecove/2.1.1-SNAPSHOT/libbluecove_ppc64.so
/usr/lib64/bluecove/2.1.1-SNAPSHOT/libbluecove_s390x.so
/usr/lib64/bluecove/2.1.1-SNAPSHOT/libbluecove_x64.so
…
/usr/share/spring/AI/Interfaces/Java/0.1/libAIInterface.so
--
Florian Weimer / Red Hat Product Security
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
