主页 / unix / 问题 / 704032
Accepted
Nepumuk
Asked: 2022-05-28 00:06:56 +0800 CST

libc6和libgcc1的相互依赖

  • 772

我发现这两个包相互依赖（在 中） libgcc1，所以没有另一个就不能存在。 这是为什么？一个包不应该依赖于另一个包而不是最终依赖于它自己......？libc6debian 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
debian apt

1 个回答

  1. Best Answer

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

    首先是BUILD依赖项：解压、修补、编译、测试或安装包所需的任何包。
    如果 Pack-D 是 Pack-foo 的构建依赖项，则在 Pack-foo 构建时需要 Pack-D 的操作发生。（vg 不在 Pack-foo 运行时）。
    有了这种依赖，（通常）就不用担心你想到的可怕的循环依赖了。Pack-D 在构建时可能毫无困难地需要 Pack-foo。例如，将 gcc 视为某些 zipper 的构建依赖项，而 zipper 本身是 gcc 的构建依赖项，因为您的包管理器依赖于 gcc 的某些压缩分发。

    秒是RUN TIME依赖项。包运行所需的任何包。语言解释器，当然是数据文件，但更普遍的是：链接阶段正确进行所需的库。
    在这些特殊情况下，您正确地认为如果 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

    那里没有循环依赖，没有什么可担心的。

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

    • 1

相关问题