On Tue, Nov 25, 2014 at 12:49 AM, Emmanuel Bourg <ebo...@apache.org> 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-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
