Open jaimergp opened 2 years ago
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
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
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 ( https://github.com/conda-forge/zeromq-feedstock/issues/25 ) ( https://github.com/conda-forge/yaml-feedstock/issues/21 ) ( https://github.com/conda-forge/libprotobuf-feedstock/issues/48 )
Think we should get a better understanding of why they differ
The same issue reported upstream https://github.com/libarchive/libarchive/issues/1857
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 (https://github.com/conda-incubator/setup-miniconda/pull/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.
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:
defaults
change to autotools
, but the end result is that we need to use the same system.
Solution to issue cannot be found in the documentation.
Issue
libarchive
, as packaged on conda-forge, follows a different SONAME scheme than the one suggested in upstream:For 3.5.2, this means
13+5=18
, solibarchive.so.18
. However, the contents of the tarballs listlibarchive.so.13.5.2
(?!) and, most importantly, it includes a symlink fromlibarchive.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
defaults
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
Environment info