Fix build for NetBSD and other OS

[moubctez]

RHash 1.4.4 seems not to build correctly on OS other that macOS and Linux. The problem is with SHARED_EXT being equal to SO_MAJ_EXT, then the tests like test "x$(LIBRHASH_SO_MAJ)" != "x$(LIBRHASH_SHARED)" fail and symbolic links are not created.

I have patched configure to restore the correct functionality:

--- configure.orig	2023-07-18 06:06:38.000000000 +0000
+++ configure
@@ -690,7 +690,6 @@ log_finish
 SHARED_PREFIX="lib"
 STATIC_PREFIX="lib"
 STATIC_EXT=".a"
-SHARED_EXT=".so.${RHASH_VERSION_MAJOR}"
 SO_MAJ_EXT=".so.${RHASH_VERSION_MAJOR}"
 SOLINK_EXT=".so"
 EXEC_EXT=
@@ -713,7 +712,7 @@ if win32; then
 elif darwin; then
   SHARED_EXT=".${RHASH_VERSION_MAJOR}.dylib"
   SOLINK_EXT=".dylib"
-elif linux; then
+else
   # use the full library version for the library file extension
   SHARED_EXT=".so.${RHASH_VERSION}"
 fi

[rhash]

Thank you for reporting this bug! I'm also glad to hear that *BSD also accept the "librhash.1.4.4" library filename.

I need time to find more correct fix, but for now you indeed can use the patch above.

[rhash]

Fixed by commit 9ef90b9.

[grobian]

9ef90b9 is not quite the same, because it now only does this for BSD. (Not sure what FreeBSD does these days...) Anyway, this is still broken on Solaris and OpenIndiana this same way. LIBRHASH_SO_MAJ may never be equal to LIBRHASH_SHARED to have a succeeding build.

(libtool actually quite well knows about versioning of shared and static libraries)

[rhash]

There was an error in the commit. Now the fix is 9ef90b9 + b8c91ea.

If the OS is nether Linux nor *BSD, then the fix uses the old naming scheme:
librhash.so (symlink) -> librhash.so.1 (shared library)

[grobian]

Ok, but Solaris and OpenIndiana just use maj.min.rev naming style on its so's. If I recall correctly, FreeBSD in the past used to just use maj and nothing else.