Align install_name on OSX with Linux

[xhochy]

Currently, the install_name on OSX is pinning to x.x.x whereas on Linux (or non-OSX), we link to librhash.so.X (i.e. only major). This brings both in line.

[rhash]

At least OpenBSD (patch) and Homebrew (script) also addresses issue with shared library suffix.

So the situation should be more carefully investigated.
A good long-term solution would be to add a configure script option to specify the library suffix, giving users more control.

[xhochy]

This depends on what kind of ABI-stability rhash would like to guarantee. From what I have seen in the recent changes, it seems like the API/ABI that one gets via librhash/rhash.h is stable and only implementation details changed. If this is the desired "support pattern", then my patch should make sense. If there are no API/ABI-guarantee between patch releases, the line below for Linux (namely LIBRHASH_SH_LDFLAGS="-shared -Wl${SHARED_VSCRIPT},-soname,\$(LIBRHASH_SO_MAJ)") should be changed to reflect this.

[rhash]

LibRHash follows the versioning scheme "librhash.so.1" (ABI version = 1) while the full version is "1.4.6".

This (major) ABI version is switched on breaking ABI changes, which includes:

• Removing symbols (functions, variables, structures)
• Changing existing symbols:
  • Modifying data structures (for example, changing the size or order of fields).
  • Changing calling conventions.
  • Changing the types of function arguments.

Adding new symbols does not break backward compatibility, so it is not a breaking ABI change.

However, some systems like OpenBSD enforce stricter rules, requiring any symbol addition to be reflected in the library suffix. Since RHash does not yet adopt semantic versioning, the library must be installed on such systems as "librhash.so.1.4.6".

[rhash]

Dynamic Library Design Guidelines for macOS says:

... you must disclose the library’s major version number in its filename. For example, the filename ... could be libDraw.A.dylib. The letter A specifies the major version number for the initial release. ... Minor revisions to the library are released under the same filename used by the previous major revision.

The minor version number is an incremental number using the format X[.Y[.Z]] , where X is a number between 0 and 65535, and Y and Z are numbers between 0 and 255. ... To set the minor version number of a dynamic library, use the clang -current_version <version_number> option.

According to this document the library name on macOS must be "librhash.1.dylib".

[xhochy]

According to this document the library name on macOS must be "librhash.1.dylib".

At the moment, both, librhash.1.dylib and librhash.1.4.6.dylib (and librhash.dylib) are installed (one is symlinked to the other). The library itself has set its install_name to librhash.1.4.6.dylib, i.e. independent of what you supply on the linker line (-lrhash…), it will always look for the variant with the full version on dynamic loading. This patch changes the behaviour to look for the librhash.1.dylib.

I think we are both in agreement. Is there anything I need to clarify more to get this merged?

[xhochy]

According to this document the library name on macOS must be "librhash.1.dylib".

At the moment, both, librhash.1.dylib and librhash.1.4.6.dylib (and librhash.dylib) are installed (one is symlinked to the other). The library itself has set its install_name to librhash.1.4.6.dylib, i.e. independent of what you supply on the linker line (-lrhash…), it will always look for the variant with the full version on dynamic loading. This patch changes the behaviour to look for the librhash.1.dylib.

I think we are both in agreement. Is there anything I need to clarify more to get this merged?