Bug#764630: missing JNI path in jarwrapper

[Emmanuel Bourg]

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