Closed chrisburr closed 9 months ago
Some more information:
libcrypt.so.1
in conda-forge's various sysroot_linux-*
packages so we assume it's alwasy availblemanylinux
removed this from their whitelist a while ago (https://github.com/pypa/manylinux/issues/305)libxcrypt
to provide libcrypt.so.1
I haven't done that much research but it seems like maybe we should be using libxcrypt
instead.
@conda-forge/core Any thoughts?
We can provide libcrypt.so.2
as part of libxcrypt
package and use it in perl, python etc and then delete the headers and libcrypt.so.1
from the sysroot. This is what we did for libnsl.so.1
being removed from glibc.
(@chrisburr edited to change libcrypto.so.2
-> libcrypt.so.2
)
That makes sense to me. I've opened a PR to staged-recipes for libxcrypt
/libxcrypt-1
: https://github.com/conda-forge/staged-recipes/pull/18377
After it's merged I'll look at making a repodata patch to make perl
depend on libxcrypt-1
(and any other packages that depend on libcrypt.so.1
).
For anyone looking for solution, you need to install libxcrypt1
package.
After it's merged I'll look at making a repodata patch to make
perl
depend onlibxcrypt-1
(and any other packages that depend onlibcrypt.so.1
).
Maybe libxcrypt-1
get renamed to libxcrypt1
?
Finally, done via gh-64.
Solution to issue cannot be found in the documentation.
Issue
When using
perl
from conda-forge on Arch Linux I see:To reproduce with docker (I'm using micromamba for convenience but I see the same with conda/mamba on a full desktop installation of Arch):
Installed packages
Environment info