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
signature.asc
Description: This is a digitally signed message part
