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 java-1.{7,8}.0-openjdk spec
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 fweimer@redhat.com [2014-07-29 07:31]:
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 java-1.{7,8}.0-openjdk spec
from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../... ?
Is it a good idea to install files from RPMs through a symbolic link?
We could use the alternatives mechanism for this.
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.
We can change (add and remove from) this path in the JDKs that we ship, if we have to.
Thanks, Omair
On 07/29/2014 04:59 PM, Omair Majid wrote:
- Florian Weimer fweimer@redhat.com [2014-07-29 07:31]:
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 java-1.{7,8}.0-openjdk spec
from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../... ?
Is it a good idea to install files from RPMs through a symbolic link?
We could use the alternatives mechanism for this.
we *must*
Those will be slaves of javac
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.
We can change (add and remove from) this path in the JDKs that we ship, if we have to.
I would like to avoid unnecessary patching here. Maybe this fix is worthy of upstreaming - to provide more general search paths?
On 07/29/2014 04:59 PM, Omair Majid wrote:
Then the most simple way is to provide symlinks in java-1.{7,8}.0-openjdk spec
from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../... ?
Is it a good idea to install files from RPMs through a symbolic link?
We could use the alternatives mechanism for this.
How so and why?
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.
We can change (add and remove from) this path in the JDKs that we ship, if we have to.
It would be nice to preserve compatibility with proprietary JDKs, too.
On 07/29/2014 05:24 PM, Florian Weimer wrote:
On 07/29/2014 04:59 PM, Omair Majid wrote:
Then the most simple way is to provide symlinks in java-1.{7,8}.0-openjdk spec
from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../... ?
Is it a good idea to install files from RPMs through a symbolic link?
We could use the alternatives mechanism for this.
How so and why?
Because you caninstallmultiple jdks in time,and you are switching among them via alternatives. The alternatives already covers jre/sdk dir, jcm exports dirs and all jre/jdk binaries llike java (and its slaves) or javac (and its slaves)
So unless you wont to have /usr/lib{,64}/some-sepcific-jdk-version1-jni /usr/lib{,64}/some-sepcific-jdk-version2-jni and so on, you have to control thos elinks in same way as bianries.
Maybe solution may be to have those /usr/lib{,64}/some-sepcific-jdk-version1-jni ... and have master switching link of /usr/lib{,64}/jni pointing to right (via alternatives selected) /usr/lib{,64}/some-sepcific-jdk-version1-jni
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.
We can change (add and remove from) this path in the JDKs that we ship, if we have to.
It would be nice to preserve compatibility with proprietary JDKs, too.
On 07/29/2014 05:29 PM, Jiri Vanek wrote:
On 07/29/2014 05:24 PM, Florian Weimer wrote:
On 07/29/2014 04:59 PM, Omair Majid wrote:
Then the most simple way is to provide symlinks in java-1.{7,8}.0-openjdk spec
from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../... ?
Is it a good idea to install files from RPMs through a symbolic link?
We could use the alternatives mechanism for this.
How so and why?
Because you caninstallmultiple jdks in time,and you are switching among them via alternatives.
Uhm, wouldn't a java-filesystem package which provides the directory (either /usr/lib64/jni or /usr/java/packages/lib/amd64, depending which one we prefer) make more sense? After all, the contents isn't JDK-specific at all.
* Florian Weimer fweimer@redhat.com [2014-07-29 11:24]:
On 07/29/2014 04:59 PM, Omair Majid wrote:
Then the most simple way is to provide symlinks in java-1.{7,8}.0-openjdk spec
from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../... ?
Is it a good idea to install files from RPMs through a symbolic link?
We could use the alternatives mechanism for this.
How so and why?
For the how, alternatives allows creating symlinks. Basically, you give it a 'master' symlink name and the 'alternative' path it could point to. It then automagically selects the 'best' path to map that symlink to. We use it extensively in the openjdk RPMS.
As for the why, it was merely a suggestion on how that scheme described above could be implemented.
I am not sure I entirely agree with the proposed scheme just yet... In fact, it looks somewhat incorrect. /usr/lib{,64}/jni is where packages install JNI .so files, but /usr/lib/jvm/java..../ is a JDK-specific path, and not suitable for installing packages into.
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.
We can change (add and remove from) this path in the JDKs that we ship, if we have to.
It would be nice to preserve compatibility with proprietary JDKs, too.
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.
Thanks, Omair
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.
On Debian, they use /usr/lib/jni (the equivalent of /usr/lib/java on Fedora). It is different because they put any jars which dlopen into /usr/lib/java.
Debian does patch openjdk to search /usr/lib/jni:/lib:/usr/lib plus the multiarch equivalent (cf. http://code.ohloh.net/file?fid=NMn8r1Wko1rlfhxLd2cwIvqpuPU&cid=vP7_57sIM8s&s=&fp=5549&mp=&projSelected=true#L0).
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
On 07/30/2014 06:13 AM, Florian Weimer wrote:
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.
Yes, I guess the idea was that the application (or its shell script) has to add the %{name} dir explicitly. It's not as easy as adding a global dir to the search path, at least.
This was a change from the original JPackage spec to when it was written up ok the Fedora wiki.
I don't really understand the idea of a private dir as the application being run that needs to know about the dir, and that application usually is not the same as %{name}.
java-devel@lists.fedoraproject.org
-
David Walluck -
Florian Weimer -
Jiri Vanek -
Omair Majid