Code review comment for lp:~james-page/ubuntu/natty/libjna-java/multiarch-fix

I'm not thrilled about this being handled in non-generic fashion within libjna-java. Why does this need to construct such a path? For native loading we should always be able defer to the built-in search path from libdl as used for dlopen().

++ } else if (Platform.isARM()) {
++ cpu = "arm";
++ kernel = "linuxapcs";
++ }

This looks like it might be based on <http://wiki.debian.org/Multiarch/Tuples>, which has been abandoned in the final multiarch implementation in favor of GNU triplets. Sorry about that, I've marked it now as obsolete on <http://wiki.debian.org/Multiarch>. The triplet used on armel is 'arm-linux-gnueabi' (linuxapcs, in any case, refers to the obsolete OABI interface).

Also, there is an armhf port pending which will also show up as 'arm' with this check, but has a different ABI for library calls and will have its libraries installed in a different path. It would be nice if any solution here was generic enough to handle this architecture too.

Finally, the rationale for this seems to be that libjna-java needs to look up unversioned libraries. This is just plain *wrong* for any caller to do with a shared library. The soname declares the ABI, and if you don't know the soname, you don't know the ABI and should not be trying to poke at its symbols. In the case of libpam.so which started this, the unversioned '.so' symlink shouldn't even be present on a normal system; it's only installed when you have libpam-dev, which should not be a runtime requirement.