Bug#764630: missing JNI path in jarwrapper
On Wed, Dec 3, 2014 at 9:06 AM, Markus Koschany wrote: [...] > On a side note: jarwrapper exports LD_LIBRARY_PATH=/usr/lib/jni. Was > this ever useful because -Djava.library.path is still used? I believe you *should* try your patch on libvtk-java package. I can't remember if each and every java module (*.so) are explictely loaded within the jar file, or if the behavior rely on existing (valid) LD_LIBRARY_PATH pointing to (sub) java modules. In other word, only /usr/lib/jni/libfoo.so is loaded but needs /usr/lib/jni/libbar.so. Thanks for preparing a patch, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764630: missing JNI path in jarwrapper
Control: tags -1 patch Mathieu Malaterre wrote: [...] > In summary: > 1. Make jexec the default binfmts (before jarwrapper) > 2. Update jarwrapper to use the above mentionned `java -d32|64` trick > to build the library path. Hi, I think we have reached a point in the release cycle when it becomes difficult to predict the outcome of implementing 1. We simply can't foresee all consequences. We know it works for dicomscope but what about all the other packages that depend on jarwrapper? Most people depend on jarwrapper because the Java policy states: "If the package installs a jar (or a symlink to a jar) as an executable the package must have an absolute dependency on *jarwrapper or an equivalent package*" Now they have certain expectations for jarwrapper and since we haven't seen any complaints except this bug report so far, we should assume that jarwrapper works in general. I suggest the following: 1. Clone this bug report, retitle to "Make jexec the default binfmts (before jarwrapper)" and lower the severity to important. This change should be discussed on debian-java anyway but it is not RC. 2. Fix this bug by applying the attached patch and removing the java.library.path from jarwrapper. As Emmanuel already said before, the openjdk packages can find the correct multiarch path and jarwrapper should let those packages handle it. 3. Please note that dicomscope could "depend on jarwrapper or an equivalent package". You could also write your own wrapper script or use java-wrappers instead. 4. I think Mathieu is right and dicomscope should install the native libraries into specific *-jni packages. The Java policy should be changed to say "must be shipped in a separate package" instead of "should". In any case dicomscope:amd64 and dicomscope:i386 are currently not co-installable, so the whole discussion about the java -d32|64 hack is rather academic at the moment. On a side note: jarwrapper exports LD_LIBRARY_PATH=/usr/lib/jni. Was this ever useful because -Djava.library.path is still used? Regards, Markus From 1039406c269fa2f33b1077c4b7f9fbca11dc17ca Mon Sep 17 00:00:00 2001 From: Markus Koschany Date: Wed, 3 Dec 2014 07:38:51 +0100 Subject: [PATCH] fix 764630 --- jarwrapper | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jarwrapper b/jarwrapper index 5986233..4ae1dd6 100755 --- a/jarwrapper +++ b/jarwrapper @@ -35,7 +35,7 @@ fi if which "$JAVA" >/dev/null 2>&1; then export LD_LIBRARY_PATH=/usr/lib/jni - exec $JAVA $JAVAOPTS -Djava.library.path=/usr/lib/jni -jar "$JAR" "$@" + exec $JAVA $JAVAOPTS -jar "$JAR" "$@" else echo "In order to run Java programs you must install a compatible JRE. If you don't know what JRE you need, default-jre is probably a good bet" fi -- 2.1.3 signature.asc Description: OpenPGP digital signature
Bug#764630: missing JNI path in jarwrapper
On Tue, Nov 25, 2014 at 12:49 AM, Emmanuel Bourg wrote: > Le 21/11/2014 17:12, Mathieu Malaterre a écrit : > >> Maybe this is time to change the Java policy §2.4 Java libraries > >> This means that dicomscope package would install only the `jar` file, >> and the x86 or x86_64 native lib (*.so) can be installed whether the >> user want the 32bits or the 64bits version. >> >> Comments ? > > The policy change is certainly a good idea, but it will not solve this > specific issue. > > For example, let say we are on an amd64 system and we install the > package libfoo-java that depends on libfoo-jni. libfoo-jni installs its > .so in a multiarch path (/usr/lib/x86_64-linux-gnu). We install the 32 > bits JRE from Oracle and set it as the default JRE. Then we run foo with > jarwrapper. jarwrapper tries to build the library path, and seeing we > are on amd64 set it to "/usr/lib:/usr/lib/x86_64-linux-gnu". foo fails > because we tried loading a 64 bits library from a 32 bits VM. That is the correct behavior. When I want to run an x86 executable (apps are not co-installable) but install the default amd64 (x86_64) it does not work (the amd64 is used instead). So to run an x86 you need to explicitly install libfoo-jni:i386, that is the intended behavior. > Actually jarwrapper has to guess the 32/64 bits architecture of the VM > and build the library path accordingly (at least for the architectures > where Oracle provides a JVM, that's amd64/i386 and maybe the arm > variants). So the logic would be: > > Are we running on amd64/i386? > -> Yes : Check if the VM is 32 or 64 bits > (by parsing the output of "java -d32 -version" >and "java -d64 -version") >-> 32 bits : set the library path to /usr/lib:/usr/lib/i386-linux-gnu >-> 64 bits : set the library path to /usr/lib:/usr/lib/x86_64-linux-gnu > -> No : this is a Debian VM and the path is ok by default, do nothing Building a proper library path for an Oracle JRE is maybe outside of debian policy ? and beyond debian-java responsabilities ? Maybe what was not clear is that jexec does have the proper behavior, jarwrapper should only be used only if the first binfmts (=jexec) fails to execute. In summary: 1. Make jexec the default binfmts (before jarwrapper) 2. Update jarwrapper to use the above mentionned `java -d32|64` trick to build the library path. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764630: missing JNI path in jarwrapper
Le 21/11/2014 17:12, Mathieu Malaterre a écrit : > Maybe this is time to change the Java policy §2.4 Java libraries > This means that dicomscope package would install only the `jar` file, > and the x86 or x86_64 native lib (*.so) can be installed whether the > user want the 32bits or the 64bits version. > > Comments ? The policy change is certainly a good idea, but it will not solve this specific issue. For example, let say we are on an amd64 system and we install the package libfoo-java that depends on libfoo-jni. libfoo-jni installs its .so in a multiarch path (/usr/lib/x86_64-linux-gnu). We install the 32 bits JRE from Oracle and set it as the default JRE. Then we run foo with jarwrapper. jarwrapper tries to build the library path, and seeing we are on amd64 set it to "/usr/lib:/usr/lib/x86_64-linux-gnu". foo fails because we tried loading a 64 bits library from a 32 bits VM. Actually jarwrapper has to guess the 32/64 bits architecture of the VM and build the library path accordingly (at least for the architectures where Oracle provides a JVM, that's amd64/i386 and maybe the arm variants). So the logic would be: Are we running on amd64/i386? -> Yes : Check if the VM is 32 or 64 bits (by parsing the output of "java -d32 -version" and "java -d64 -version") -> 32 bits : set the library path to /usr/lib:/usr/lib/i386-linux-gnu -> 64 bits : set the library path to /usr/lib:/usr/lib/x86_64-linux-gnu -> No : this is a Debian VM and the path is ok by default, do nothing -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764630: missing JNI path in jarwrapper
On Fri, Nov 21, 2014 at 12:23 PM, Emmanuel Bourg wrote: > On Thu, 30 Oct 2014 10:36:02 +0100 Mathieu Malaterre > wrote: > >> Currently jarwrapper is used as backend for binfmts (not sure why this >> is not jexec). Anyway the script is incomplete, now that we have >> multi-arch JNI location: > > This is tricky, because if we add the multi arch path based on the > output of dpkg-architecture, we'll still get an error with a 32 bits JRE > on a 64 bits system. The java.library.path parameter would point to > /usr/lib/x86_64-linux-gnu when it should actually include > /usr/lib/i386-linux-gnu. > > A solution would be to remove the java.library.path parameter from > jarwrapper. The openjdk-*-jre packages already include the right > multiarch path so it's not necessary to add this parameter in this case > (I verified dicomscope starts without it). But if an Oracle VM is used > instead it would still break. Maybe this is time to change the Java policy §2.4 Java libraries From: [...] These dynamic libraries should be shipped in a separate architecture-specific package named libXXX[version]-jni. [...] to: [...] These dynamic libraries *must* be shipped in a separate architecture-specific package named libXXX[version]-jni. [...] This means that dicomscope package would install only the `jar` file, and the x86 or x86_64 native lib (*.so) can be installed whether the user want the 32bits or the 64bits version. Comments ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764630: missing JNI path in jarwrapper
On Thu, 30 Oct 2014 10:36:02 +0100 Mathieu Malaterre wrote: > Currently jarwrapper is used as backend for binfmts (not sure why this > is not jexec). Anyway the script is incomplete, now that we have > multi-arch JNI location: This is tricky, because if we add the multi arch path based on the output of dpkg-architecture, we'll still get an error with a 32 bits JRE on a 64 bits system. The java.library.path parameter would point to /usr/lib/x86_64-linux-gnu when it should actually include /usr/lib/i386-linux-gnu. A solution would be to remove the java.library.path parameter from jarwrapper. The openjdk-*-jre packages already include the right multiarch path so it's not necessary to add this parameter in this case (I verified dicomscope starts without it). But if an Oracle VM is used instead it would still break. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764630: missing JNI path in jarwrapper
reassign 764630 jarwrapper 0.47 retitle 764630 missing JNI multi-arch PATHs in jarwrapper thanks Currently jarwrapper is used as backend for binfmts (not sure why this is not jexec). Anyway the script is incomplete, now that we have multi-arch JNI location: [...] $ tail /usr/bin/jarwrapper if [ -z "$JAVA" ]; then JAVA=java fi if which "$JAVA" >/dev/null 2>&1; then export LD_LIBRARY_PATH=/usr/lib/jni exec $JAVA $JAVAOPTS -Djava.library.path=/usr/lib/jni -jar "$JAR" "$@" else echo "In order to run Java programs you must install a compatible JRE. If you don't know what JRE you need, default-jre is probably a good bet" fi [...] Please update `LD_LIBRARY_PATH` accordingly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
