Bug#764630: missing JNI path in jarwrapper

[Mathieu Malaterre]

On Tue, Nov 25, 2014 at 12:49 AM, Emmanuel Bourg <ebourg at 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.