Início / unix / Perguntas / 704032
Accepted
Nepumuk
Asked: 2022-05-28 00:06:56 +0800 CST

Dependência mútua de libc6 e libgcc1

  • 772

Descobri que os dois pacotes libgcc1e libc6dependem um do outro (em debian 10), então nenhum pode existir sem o outro.
Por que é que? Um pacote não deveria depender de outro e não de si mesmo…?

$ 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 respostas

  1. Best Answer

    Do ponto de vista do gerenciador de pacotes, existem vários tipos de dependências .

    As primeiras vêm as dependências BUILD : Quaisquer pacotes necessários para descompactar, corrigir, compilar, testar ou instalar o pacote.
    Se o Pack-D for uma dependência de compilação do Pack-foo, uma ocorrência operacional do Pack-D será necessária no momento da compilação do Pack-foo. (vg não em tempo de execução do Pack-foo).
    Com esse tipo de dependência, não há (em geral) medo da assustadora dependência circular em que você pensa. O Pack-D pode, sem problemas, precisar do Pack-foo no momento da compilação. Pense, por exemplo, no gcc como uma dependência de compilação de algum zíper e o próprio zíper sendo uma dependência de compilação do gcc porque seu gerenciador de pacotes depende de alguma distribuição compactada do gcc.

    Segundos são dependências RUN TIME . Quaisquer pacotes necessários para que o pacote seja executado. Intérpretes de linguagem, arquivos de dados, é claro, mas de forma mais geral: bibliotecas que são necessárias para que a fase de link prossiga corretamente.
    Nesses casos em particular, você está correto sentindo que se lib-A é uma dependência de tempo de execução de lib-B, então lib-B não deve ser uma dependência de tempo de execução de lib-A, pois isso criaria uma dependência circular a ser evitada em qualquer caso.

    ldd ou lddtree são boas ferramentas para obter o conhecimento dessas dependências. No meu sistema, lddtree diria que o libc6 é na verdade uma dependência de tempo de execução do 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

    Mas essa libgcc1 não é uma dependência de tempo de execução de 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

    Nenhuma dependência circular lá, nada para se preocupar então .

    Os terços são BLOQUEADORES : Alguns gerenciadores de pacotes (gentoo portage por exemplo) enganam as declarações de dependências para especificar pacotes que devem ou não coexistir em um sistema. Claro que isso não constitui dependências circulares.

    • 1

relate perguntas