SONAMEs follow different scheme than upstream (e.g. `so.13.5.2` vs `so.18`)

[jaimergp]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

libarchive, as packaged on conda-forge, follows a different SONAME scheme than the one suggested in upstream:

# INTERFACE_VERSION increments with every release
# libarchive 2.7 == interface version 9 = 2 + 7
# libarchive 2.8 == interface version 10 = 2 + 8
# libarchive 2.9 == interface version 11 = 2 + 9
# libarchive 3.0 == interface version 12
# libarchive 3.1 == interface version 13
math(EXPR INTERFACE_VERSION  "13 + ${_minor}")

# Set SOVERSION == Interface version
# ?? Should there be more here ??
SET(SOVERSION "${INTERFACE_VERSION}")

For 3.5.2, this means 13+5=18, so libarchive.so.18. However, the contents of the tarballs list libarchive.so.13.5.2 (?!) and, most importantly, it includes a symlink from libarchive.so.13 -> libarchive.so.13.5.2, which would make this version collide with a (correctly SONAMEd) libarchive 3.1.

Compare this to defaults:

conda-forge

libarchive-3.5.2-hb890918_2.tar.bz2
-rw-rw-r--  0 1001   1001  1818396 May 18 09:00 lib/libarchive.a
-rw-rw-r--  0 1001   1001      871 May 18 09:00 lib/pkgconfig/libarchive.pc
-rwxrwxr-x  0 1001   1001   921896 May 18 09:00 lib/libarchive.so.13.5.2
lrwxrwxrwx  0 1001   1001        0 May 18 09:00 lib/libarchive.so -> libarchive.so.13.5.2
lrwxrwxrwx  0 1001   1001        0 May 18 09:00 lib/libarchive.so.13 -> libarchive.so.13.5.2
libarchive-3.5.2-hccf745f_0.tar.bz2
lrwxrwxrwx  0 1001   1001        0 Aug 27  2021 lib/libarchive.so -> libarchive.so.13.5.2
-rw-rw-r--  0 1001   1001      871 Aug 27  2021 lib/pkgconfig/libarchive.pc
-rwxrwxr-x  0 1001   1001   916664 Aug 27  2021 lib/libarchive.so.13.5.2
lrwxrwxrwx  0 1001   1001        0 Aug 27  2021 lib/libarchive.so.13 -> libarchive.so.13.5.2
-rw-rw-r--  0 1001   1001  1808436 Aug 27  2021 lib/libarchive.a
libarchive-3.5.2-hccf745f_1.tar.bz2
lrwxrwxrwx  0 1001   1001        0 Sep 25  2021 lib/libarchive.so.13 -> libarchive.so.13.5.2
-rw-rw-r--  0 1001   1001  1808436 Sep 25  2021 lib/libarchive.a
lrwxrwxrwx  0 1001   1001        0 Sep 25  2021 lib/libarchive.so -> libarchive.so.13.5.2
-rw-rw-r--  0 1001   1001      871 Sep 25  2021 lib/pkgconfig/libarchive.pc
-rwxrwxr-x  0 1001   1001   916664 Sep 25  2021 lib/libarchive.so.13.5.2

defaults

libarchive-3.5.2-h5de8990_0.tar.bz2
-rw-rw-r--  0 0      0         930 Jun  3 13:21 lib/pkgconfig/libarchive.pc
lrwxrwxrwx  0 0      0           0 Jun  3 13:22 lib/libarchive.so -> libarchive.so.18
-rw-rw-r--  0 0      0     1813266 Jun  3 13:22 lib/libarchive.a
-rwxrwxr-x  0 0      0      912576 Jun  3 13:22 lib/libarchive.so.18

---

Looks like defaults relies on CMake while conda-forge uses autotools, which might explain the difference. I think the bug is that what should be an arithmetical addition (13 + 5) is being treated as a string concatenation (13 + "5.2").

Fixing this would involve rebuilding downstream packages I guess.

Installed packages

N/A

Environment info

N/A

[jaimergp]

This is also a problem in macOS, but even worse. On macOS, the dylibs are versioned only with the base version (13, which is equivalent to 3.1), so we can't technically symlink to the correct one, because that'd be ABI breaking. It's true though that conda-forge never packaged libarchive 3.1, so... it could work as long as we never do it :D

[jaimergp]

Details:

Defaults

$ tar -tvf libarchive-3.5.2-ha0e9c3a_0.tar.bz2| grep lib/ 
-rw-rw-r--  0 502    20    1231616 Jun  3 11:41 lib/libarchive.a
-rw-rw-r--  0 502    20        611 Jun  3 11:41 lib/pkgconfig/libarchive.pc
lrwxrwxr-x  0 502    20          0 Jun  3 11:41 lib/libarchive.dylib -> libarchive.18.dylib
-rwxrwxr-x  0 502    20     837124 Jun  3 11:41 lib/libarchive.18.dylib

conda-forge

$ tar -tvf libarchive-3.5.2-hbf7dfe4_2.tar.bz2 | grep lib/ 
-rw-rw-r--  0 501    20    1244152 May 18 09:06 lib/libarchive.a
-rw-rw-r--  0 501    20        872 May 18 09:06 lib/pkgconfig/libarchive.pc
lrwxrwxr-x  0 501    20          0 May 18 09:06 lib/libarchive.dylib -> libarchive.13.dylib
-rwxrwxr-x  0 501    20     841024 May 18 09:06 lib/libarchive.13.dylib

[jakirkham]

Think we are just using autotools to build here. So not sure why they differ

That said, know in some cases moving to CMake hasn't worked for other packages in place of autotools ( conda-forge/zeromq-feedstock#25 ) ( conda-forge/yaml-feedstock#21 ) ( conda-forge/libprotobuf-feedstock#48 )

Think we should get a better understanding of why they differ

[jaimergp]

The same issue reported upstream libarchive/libarchive#1857

[jaimergp]

This keeps coming up as people mix conda-forge and defaults, and will be more prominent when libmamba becomes the solver default. I can even reproduce it with a fairly barebones setup-miniconda input (conda-incubator/setup-miniconda#291), so I'd like to come up with a solution here.

I am going to revamp #70 and see what we have to do.

[jaimergp]

After checking with Isuru (thanks a bunch!), we can't just use symlinks for this because ABI compatibility is not guaranteed. Instead, we'll have to:

1. autotool/libtool's versioning was right all along, CMake was the buggy one! I sent a PR upstream to fix their CMake config (Fix SOVERSION computation logic in CMake to match libtool's libarchive/libarchive#1976).
2. On the next minor release, change to CMake or have defaults change to autotools, but the end result is that we need to use the same system.