Anaconda Conda打包和作为依赖项的C库

Conda在控制包的必要依赖项方面做得很好，但显然大多数包都将C库排除在可跟踪依赖项之外。例如，让我们使用以下命令安装Gnuastro：

conda install -c conda-forge gnuastro

然后，我查看Gnuastro的一个程序所链接的库（例如

astnoisecisel

）：

除了C库之外，所有使用的高级库都在Conda环境中：

libm.so.6

，

libc.so.6

，

libpthread.so.0

，

librt.so.1

，

libdl.so.2

，

libresolv.so.2

，当然还有

ld-linux-x86-64.so.2

我在Conda forge上找不到GNU C库，但当我进行搜索时，我找到了其他一些有GNU C库的项目。例如，我试着：

conda install -c neok.m4700 glibc

这个安装的GNU C库2.30（Conda tarball创建于3个月前）和上面的

ldd

命令为我提供了一个关于Conda安装中所有内容的漂亮列表。在一个测试环境中，对

astnoisecisel--version

的调用给出了一个分段错误，在另一个环境中成功了。然后我尝试了另一个Conda C库（在干净的环境中）：

这是C库的旧版本（最近一次更新是在5年前：Glibc2.19）。在这种环境中，我的

astnoisecisel--version

命令只会给出分段错误和崩溃

在中，有人说“glibc是一种不好的产品，如果我们不能使用系统glibc，我担心这个软件包。它与内核版本紧密相关，使用旧版本也会带来安全风险”。因此，我猜他们的策略不是包含GNUC库（至少在GNU/Linux系统上）

我在Anaconda中也看到了类似的“基本”包问题。例如，当我检查

curl

或

zstd

的链接标志时

所以我的问题是：如果C库没有正式定义为依赖项（像所有其他依赖项一样），那么在不久的将来（像上面的5年），Conda包（特别是对于较旧版本的软件）的可靠性如何

---

类似地，假设我需要手动获取用于构建Conda包的正确C库（以便能够运行可执行文件）。在下载的tarball中，是否记录了构建该软件包时使用的C库版本？

我的理解是，康达软件包应基于最古老的合理可用C库构建。我相信

defaults

频道使用的是CentOS版本，其Linux软件包中有一个稍旧的

glibc

。这种方法的优点是，一般来说，

glibc

是向后兼容的，因此针对较旧版本进行编译可以在使用较新的

glibc

的操作系统上运行，但反过来就不行了。AFAIK，这如何影响再现性还没有答案，但我认为没有人对此有好的答案_(ツ)_/“'虽然libc不是作为依赖项提供的，但程序包仍然链接到它，并且它将找到系统libc，而不是在conda环境中被提供的libc绑定。您显示的ldd输出证实了这一点。@darthbith的评论是这个问题的正确答案。我还应该注意，这不是conda程序包所独有的，Python轮子也有同样的问题。事实上，任何依赖于

libc

的二进制依赖都会有同样的问题。责任必须在某个地方停止……这是源代码发行版的最大优势之一，用户能够根据本地

libc

进行编译，因此他们知道它可以在自己的计算机上工作。O当然，他们必须安装编译器工具链……conda forge生态系统中构建的软件包以特定的内核版本和使用Linux系统根目录的glibc版本为目标。至于旧版本的软件包在5年后如何在现代系统上继续工作，请阅读：

conda install -c neok.m4700 glibc

conda install -c asmeurer glibc