☰

libc6和libgcc1的相互依赖

tag-icon • tag-icon debian apt dependencies
libc6和libgcc1的相互依赖

我发现这两个包libgcc1和libc6相互依赖（在debian 10），因此没有一个可以单独存在。
这是为什么？难道一个包不应该依赖于另一个包而不是最终依赖于它自己吗？

$ LC_ALL=C apt depends libgcc1 libc6
libgcc1
  Depends: gcc-8-base (= 8.3.0-6)
  Depends: libc6 (>= 2.14)
  Breaks: <gcc-4.3> (<< 4.3.6-1)
  Breaks: <gcc-4.4> (<< 4.4.6-4)
  Breaks: <gcc-4.5> (<< 4.5.3-2)
libc6
  Depends: libgcc1
  Conflicts: openrc (<< 0.27-2~)
  Breaks: <hurd> (<< 1:0.5.git20140203-1)
  Breaks: <libtirpc1> (<< 0.2.3)
  Breaks: locales (<< 2.28)
  Breaks: locales-all (<< 2.28)
  Breaks: nocache (<< 1.1-1~)
  Breaks: nscd (<< 2.28)
  Breaks: r-cran-later (<< 0.7.5+dfsg-2)
  Recommends: libidn2-0 (>= 2.0.5~)
  Suggests: glibc-doc
 |Suggests: debconf
  Suggests: <debconf-2.0>
    cdebconf
    debconf
  Suggests: libc-l10n
  Suggests: locales

答案1

从包管理器的角度来看，有几种类型依赖关系。

首先是建造依赖项：解压、修补、编译、测试或安装包所需的任何包。
如果 Pack-D 是 Pack-foo 的构建依赖项，则在 Pack-foo 构建时需要运行 Pack-D。 （vg 不在 Pack-foo 运行时）。
有了这种依赖性，（一般来说）就不用担心可怕的事情了循环依赖你想想。 Pack-D 在构建时可能会毫无问题地需要 Pack-foo。例如，将 gcc 视为某些 zipper 的构建依赖项，而 zipper 本身是 gcc 的构建依赖项，因为您的包管理器依赖于 gcc 的某些压缩发行版。

秒数是运行依赖关系。包运行所需的任何包。当然是语言解释器、数据文件，但更一般地说：链接阶段正确进行所需的库。
在这些特殊情况下，您的感觉是正确的，如果 lib-A 是 lib-B 的运行时依赖项，那么 lib-B 不应该反过来成为 lib-A 的运行时依赖项，因为这会创建要避免的循环依赖项任何状况之下。

ldd 或 lddtree 是了解这些依赖关系的好工具。在我的系统上，lddtree 会告诉您 libc6 实际上是 libgcc1 的运行时依赖项

# lddtree /usr/lib/gcc/x86_64-pc-linux-gnu/9.4.0/libgcc_s.so.1
libgcc_s.so.1 (interpreter => None)
    libc.so.6 => /lib64/libc.so.6
        ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2

但 libgcc1 不是 libc6 的运行时依赖项：

# lddtree /usr/lib/gcc/x86_64-pc-linux-gnu/9.4.0/lib64/libc.so.6 
/lib64/libc.so.6 (interpreter => /lib64/ld-linux-x86-64.so.2)
    ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2

那里没有循环依赖，那就没什么好担心的了。

三分之二是阻滞剂：一些包管理器（例如gentoo portage）欺骗依赖关系声明来指定应该或不应该在系统中共存的包。当然这些并不构成循环依赖。

相关内容