Add some loading mechanism with library name and ABI version

[larskanis]

I though about adding some loading mechanism with ABI version like this extracted from ruby-vips:

# Generate a library name for ffi.
#
# Platform notes:
# linux:
#   Some distros allow "libvips.so", but only if the -dev headers have been
#   installed. To work everywhere, you must include the ABI number.
#   Confusingly, the file extension is not at the end. ffi adds the "lib"
#   prefix.
# mac:
#   As linux, but the extension is at the end and is added by ffi.
# windows:
#   The ABI number must be included, but with a hyphen. ffi does not add a
#   "lib" prefix or a ".dll" suffix.
def library_name(name, abi_number)
  if FFI::Platform.windows?
    "lib#{name}-#{abi_number}.dll"
  elsif FFI::Platform.mac?
    "#{name}.#{abi_number}"
  else
    "#{name}.so.#{abi_number}"
  end
end

For libvips the library file names are:

• libvips-42.dll on Windows
• libvips.so.42 on Linux
• libvips.42.dylib on Macos

This file name pattern is pretty standard on Linux and other UNIXes and the corresponding Windows pattern is getting more common these days at least on MINGW/MSYS2. Not sure how library naming is done on MSVC. They change DLL loading mechanisms every some years (SxS, explicit DLL version names, API sets). Do you know how common the MacOS-pattern is (I don't know much about MacOS)?

[larskanis]

@jcupitt answered here:

I checked on my mac and they seem to be libNAME.ABI.dylib, so libglib-2.0.0.dylib, in this example. That's certainly how Anaconda and homebrew name their libraries, at least.

They have a symlink from libNAME.dylib to the most recent ABI, but I don't know if those are always present. In any case, including the ABI version should always locate the correct library. I hope.

You're right, Windows is much more complex. The NAME-ABI.dll pattern works for the libraries I use, but I'm sure many other standards exist.

[ioquatix]

This is a great idea.