Bug#620122: Impact of switching to multi-arch on Java & native library handling.

[James Page]

Hi All

You may (or may not) know that Ubuntu Natty (the current development
release) has started to make the transition to multi-arch based
libraries (see [0] & [4]). 

This basically means that instead of libraries being located
in /usr/lib:/lib they are installed to architecture specific locations
(/usr/lib/i386-linux-gnu...), allowing libraries for multiple archs to
be installed on the same system (i386 and amd64 for example).

For the majority of Java code this will have no impact as the JVM
abstracts this underlying change away from the developer; however code
that integrates with native libraries is potentially impacted by this
change (see [1] & [2]).  

We encountered two separate issues in Ubuntu related to this
switch-over:

1) Incomplete library search paths

        openjdk-6 and libjna-java have both been updated to be
        multi-arch aware when generating paths for library searching;
        This was a fairly simple fix but it will need to be expanded to
        support all of the various architectures that Debian builds for
        over and above Ubuntu (see [3]).
        
        I have submitted the patch to libjna-java back upstream (see
        [2]) with these comments as anyone using JNA on a multi-arch
        enabled Linux distro will have this issue.

2) Version-less library names.
        
        The second issue (which is not directly related to the
        multi-arch change) related to how native libraries are typically
        loaded in Java code.  Calls to the loadLibrary function provided
        by the Java Runtime Environment simply take library names - for
        example 'pam'.  The JVM maps this to 'libpam.so' and then tries
        to resolve this against the native libraries on the system.
        
        This is OK where a library provides both the Java code and the
        native shared object (without a ABI version number) which should
        be installed to /usr/lib/jni.  However where the Java code is
        relying on a system library such as PAM this is unresolvable -
        i.e. the JRE will not be able to load the library as there is no
        version-less .so available.
        
        libjna-java works in a similar way but resolves this issue by
        'best matching' the library - i.e. it takes a guess at which
        version is required and picks the highest one it finds - this is
        inherently a little dangerous as the Java 'native' code might
        not map to the version it picks to load.
        
        libjna-java also understands versioned libraries and passes
        these directly to libdl to resolve - 'libpam.so.0' would be
        handled in this way.  This would be a better way to ensure that
        native Java integration is fixed and tested against a specific
        ABI version of the underlying native library.

The intent of this email is really to:

        a) give the team a heads-up on issue 1) as I believe Wheezy is
        due to move to multi-arch.
        
        b) generate some discussion around version-less system library
        handling. Hoping that JNA will match a request for 'xx' to the
        right version of library 'xx' does not feel like a good thing to
        be doing.

I don't think that this issue is particularly widespread in the Java
code-base in Debian or Ubuntu (not many libraries use libjna-java);
however I have at least two new packages I want to contribute that use
JNA in this way and it would be great to get a consensus on how to
handle this in Debian and derivatives.  

I think that fixing to a particular version of a library is the right
way to go - this can be managed using a patch and ensures that ABI
compatibility is maintained between the Java library and the native
system library for this type of package.

Cheers

James


[0] https://wiki.ubuntu.com/MultiarchSpec
[1] https://bugs.launchpad.net/ubuntu/+source/libjna-java/+bug/737603
[2] http://java.net/jira/browse/JNA-184
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620122
[4] http://wiki.debian.org/Multiarch/

James Page
Software Engineer, Ubuntu Server Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20110330/6cb6e309/attachment.pgp>