Comment 13 for bug 737603

Looking at the code in libjna-java, it appears that it already supports fallback to the system path. If the caller is fixed to (properly) look for libpam.so.0 instead of libpam.so, does that solve the issue?

> its definitely possible that applications that rely on JNI integration might
> not work after the multi-arch change as some of the unversioned
> (libpam.so for example) native libraries have moved out into -dev packages.

This has nothing to do with multiarch. the unversioned .so was *never* in the runtime library package, and is not the filename that anything should be referencing at runtime.