libleveldb shared library name does not match platform conventions on macOS

[ryandesign]

Hello, I'm a developer with the MacPorts package management system.

The name of the libleveldb shared library, and its embedded install_name, does not match the conventions of macOS.

For example, installing leveldb 1.18 via MacPorts, these files are installed:

$ ls -l /opt/local/lib/libleveldb*
-rw-r--r--  1 root  wheel  991072 Oct 16 16:01 /opt/local/lib/libleveldb.a
lrwxr-xr-x  1 root  wheel      21 Oct 16 16:01 /opt/local/lib/libleveldb.dylib -> libleveldb.dylib.1.18
lrwxr-xr-x  1 root  wheel      21 Oct 16 16:01 /opt/local/lib/libleveldb.dylib.1 -> libleveldb.dylib.1.18
-rwxr-xr-x  1 root  wheel  625960 Oct 16 16:01 /opt/local/lib/libleveldb.dylib.1.18

And the shared libraries have this install_name:

$ otool -L /opt/local/lib/libleveldb.dylib
/opt/local/lib/libleveldb.dylib:
    /opt/local/lib/libleveldb.dylib.1 (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libsnappy.1.dylib (compatibility version 5.0.0, current version 5.0.0)
    /opt/local/lib/libtcmalloc.4.dylib (compatibility version 7.0.0, current version 7.6.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

On macOS, the library version number does not go after the filename extension; it goes before. So the library should not be "libleveldb.dylib.1"; it should be "libleveldb.1.dylib".

This problem was noticed by the Homebrew package management system as well in Homebrew/legacy-homebrew#14440. There was a comment there that an upstream issue should be submitted, but I don't know if one ever was, so I'm submitting this one now.

I have patched the build system to fix this and will submit a pull request shortly.

[cmumford]

The build process has switched from make to CMake and no longer creates versioned library symbolic links.