Fix SOVERSION computation logic in CMake to match libtool's

[jaimergp]

Closes #1857

It also adds MACHO_{COMPATIBILITY,CURRENT}_VERSION as recommended in CMake docs to match libtool's output. However, these properties require CMake >=3.17. Is it ok to bump it?

Before this PR

Given libarchive 3.6.2, autotools produces:

$ otool -L libarchive.13.dylib 
.../libarchive.13.dylib:
        @rpath/libarchive.13.dylib (compatibility version 20.0.0, current version 20.2.0)
        ....

CMake gives:

$ otool -L libarchive.19.dylib 
.../libarchive.19.dylib:
        @rpath/libarchive.19.dylib (compatibility version 19.0.0, current version 0.0.0)
        ...

Note:

• Different install name
• Different compatibility and current versions

After this PR

Both systems should produce the same install name, compatibility and current versions:

$ otool -L libarchive.13.dylib 
.../libarchive.13.dylib:
        @rpath/libarchive.13.dylib (compatibility version 20.0.0, current version 20.2.0)
        ....

[evelikov]

Was speaking to a friend a few months back about the different DSO across autotools/cmake builds. Big thanks for taking a stab at this.

Few things worth* nothing:

• decreasing the DSO version is usually a bad idea, although
• Arch, Fedora, Gentoo, Debian - and maybe more linux distros - use the autotools build
• others would need to either rebuild or have a local symlink hack until they can rebuild

With this PR my Arch box shows identical SONAME (yay) although the filename still differs libarchive.so.13.7.3 (autotools) vs libarchive.so.13 (cmake). Can we fix that as well please?

Looking at the PR itself - please squash the commits into one.

[jaimergp]

With this PR my Arch box shows identical SONAME (yay) although the filename still differs libarchive.so.13.7.3 (autotools) vs libarchive.so.13 (cmake). Can we fix that as well please?

I think last commit fixes that, but it feels a bit hacky? Not sure if there's a better way.

Note this produces the same files in both platforms:

Linux:

$PREFIX/lib/libarchive.so -> libarchive.so.13
$PREFIX/lib/libarchive.so.13 -> libarchive.so.13.7.3
$PREFIX/lib/libarchive.so.13.7.3

$ objdump -p libarchive.so.13.7.3 | grep SONAME
  SONAME               libarchive.so.13

macOS:

$PREFIX/lib/libarchive.13.7.3.dylib
$PREFIX/lib/libarchive.13.dylib -> libarchive.13.7.3.dylib
$PREFIX/lib/libarchive.dylib -> libarchive.13.7.3.dylib

$ otool -L libarchive.13.7.3.dylib 
libarchive.13.7.3.dylib:
        @rpath/libarchive.13.dylib (compatibility version 21.0.0, current version 21.3.0)

Not sure if we want the "full soversion" in macOS too, but there's a symlink so 🤷

[evelikov]

I think last commit fixes that

Confirmed that it fixes that over here.

Note this produces the same files in both platforms

IMHO that's fine.

[kientzle]

decreasing the DSO version is usually a bad idea, although

Reiterating: the library version number can NEVER decrease. Making the version numbers the same is a good idea, but that must be done by increasing the lower value.

[evelikov]

Updating the autotools version will lead to massive rebuilds in most linux distros. They are well suited for that, although I would request that maintainers add a clear NOTE either way - cmake downrev or autotools uprev - in the release notes.

Thanks in advance

[evelikov]

@theta682 the existing CMakefile already has a mix of lower/uppercase so, I'm not sure if highlighting/fixing every instance is helpful here.

The indirect poke on the other hand is greatly appreciated.

@kientzle @mmatuska can we help get this (or variant thereof) merged? AFAICT @kientzle's comment have been addressed a while back.

[evelikov]

@mmatuska @kientzle humble poke? Can I "squash and merge" or you prefer to handle it?