LocateLibrary Filename filter doesn't locate libraries in some instances (Platform$Linux.locateLibrary()).

[dkartaschew]

There is an issue with the locateLibrary method in Platform$Linux.locateLibrary() method ( https://github.com/jnr/jnr-ffi/blob/master/src/main/java/jnr/ffi/Platform.java Line 424), in that it only looks for: lib.so or lib.so.[0-9]+. which may miss some instances of libraries that don't follow this convention.

For example, on Debian/Ubuntu, libssl (part of OpenSSL) is installed only as /lib/x86_64-linux-gnu/libssl.so.1.0.0 (eg, https://packages.debian.org/sid/amd64/libssl1.0.0/filelist for full list). The current regex will fail to locate this library.

The obvious temporary work around is to symlink libssl.so.1.0.0 to libssl.so.1 (or just libssl.so), but this will have to be done for all instances of libraries that don't do this already, and makes it painful for software developers having to support multiple OS installations.

While personally I believe this is a distribution issue (for not installing all libraries with the expected convention), JNR should also be smart enough to handle these types of oddities with shared libraries.

I've tested changing the regex pattern to
Pattern p = Pattern.compile("lib" + libName + "\.so(\.[0-9]+)*$");
and this appears to work well, and this new pattern no longer requires testing for an exact match either, as the pattern simple looks for "libssl.so" followed by zero or more ".[0-9]+" number groups. The alternative is to remove the last $ from the original regex pattern, so it doesn't match end of string...

Additionally, when scanning for highest version, the substring() method (line 453) will have to handle the new format (mulitple groups of version digits) as well,
eg
String num = path.substring(path.lastIndexOf(".so.") + 4);
num = num.substring(0, num.indexOf("."));

The above only takes into account the first digit, but this was good enough for our implementations.

[pepijnve]

I have the exact same issue with libcrypto.so on Debian/Ubuntu. Only the dev package contains the .so. symlink.
Is there a technical reason to only check for single component version numbers?

[headius]

I agree JNR should be smarter here, but we'd need some assistance fixing it. Someone want to take a stab at a PR?

[pepijnve]

I implemented a fix for this in #76
It changes the lookup logic to find all versioned variants of a library and chooses the one with the highest, most precise version number. So 1 > 0, 1.1 > 1.0 and 1.1.0 > 1.1.

[mkristian]

the PR looks good to me

[headius]

Fixed by #76.