Fix libsvm name for Darwin

[carlocab]

On macOS, shared libraries are expected to be installed with the naming
convention

lib$NAME.$SOVERSION.dylib

We also prefix the library install name with @rpath to indicate to the
dynamic linker that it should use RPATH to look for libsvm. Without
this, the dynamic linker will only search the calling process' current
working directory, which will, in general, not contain libsvm.

[chcwww]

We are not sure whether the change affects compatibility with previous versions on macOS.
Also, we are wondering if there is a bug or error in the current version when compiling on macOS that requires fixing.
Could you provide more details about it? Thanks.

[carlocab]

We are not sure whether the change affects compatibility with previous versions on macOS.

This does affect compatibility, so it can/should probably wait until you bump SHVER, since clients of libsvm will need to be re-linked in that case anyway (and will be able to use the new libsvm.5.dylib with no further changes).

Also, we are wondering if there is a bug or error in the current version when compiling on macOS that requires fixing. Could you provide more details about it? Thanks.

Regarding naming, it's not so much an error, but I think it is a bug to not be following platform naming conventions for shared libraries. .dylib is the default extension for shared libraries found on macOS. It's also the default extension generated by build tools like CMake or Meson.

Merging this patch also means that downstream packagers don't have to fix up the file name and install name for you. See:

• https://github.com/Homebrew/homebrew-core/blob/62f9159ad31e253977e24f305642ebfaca5e4aaf/Formula/libsvm.rb#L29-L31
• https://github.com/macports/macports-ports/blob/ccd8670f1872a1360973b6b7f448387320b42d9e/math/libsvm/files/patch-Makefile.diff
• https://github.com/NixOS/nixpkgs/blob/574d1eac1c200690e27b8eb4e24887f8df7ac27c/pkgs/development/libraries/libsvm/default.nix#L26

Homebrew, MacPorts, and Nix are probably the three most widely used package managers on macOS at the moment, and they all rename libsvm.so.* to libsvm.*.dylib.

It seems to me that there would be less duplication of effort (and therefore more efficient) if this was corrected here upstream instead.

[carlocab]

Regarding the install name, what kind of details were you looking for?

In its current state you can only link with libsvm if it's in your current working directory. If you cd to somewhere else the dynamic linker will error out saying it cannot find libsvm.

With the @rpath prefix, you can pass the appropriate -rpath flag to ld so that it knows where to find libsvm.

[chcwww]

Thanks for the information.
However, could you please provide details about the situations in which the dynamic linker cannot find libsvm with .so, and how this issue can be fixed using.dylib? (For example, where libsvm and the thing you want to link are installed, and how you link them.) Thank you.