50

Gentooを使用しているため、更新プログラムが古いバージョンのライブラリに対してリンクされていることがよくあります。通常、revdep-rebuildはそれを解決するのに役立ちますが、今回はPythonライブラリへの依存関係であり、それを取得しpython-updaterません。

lddどの共有ライブラリがどの別の共有ライブラリに依存しているかを示す「階層的」バリアントはありますか？ほとんどの場合、ライブラリと実行可能ファイルは、他の少数の共有ライブラリに対してのみリンクされており、共有ライブラリは、少数に対してリンクされており、ライブラリの依存関係を大きなリストに変えています。アップグレードした別のライブラリの新しいバージョンで再構築する必要がある依存関係を知りたいです。

4

4 に答える 4

96

多くの興味深い詳細が表示されますが、質問に対する直接的な回答はありません。

の「階層」バージョンは次のとおりlddですlddtree(からapp-misc/pax-utils):

$ lddtree /usr/bin/xmllint 
xmllint => /usr/bin/xmllint (interpreter => /lib64/ld-linux-x86-64.so.2)
    libreadline.so.6 => /lib64/libreadline.so.6
        libncurses.so.5 => /lib64/libncurses.so.5
            libdl.so.2 => /lib64/libdl.so.2
    libxml2.so.2 => /usr/lib64/libxml2.so.2
        libicui18n.so.49 => /usr/lib64/libicui18n.so.49
            libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32/libstdc++.so.6
                ld-linux.so.2 => /lib64/ld-linux.so.2
            libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32/libgcc_s.so.1
        libicuuc.so.49 => /usr/lib64/libicuuc.so.49
        libicudata.so.49 => /usr/lib64/libicudata.so.49
        libz.so.1 => /lib64/libz.so.1
        liblzma.so.5 => /usr/lib64/liblzma.so.5
        libm.so.6 => /lib64/libm.so.6
    libpthread.so.0 => /lib64/libpthread.so.0
    libc.so.6 => /lib64/libc.so.6
于 2012-08-18T07:58:56.313 に答える
24

Portage≥2.2をで実行している場合は、必要に応じて古いバージョンが保持されるため、これ以上FEATURES=preserve-libs必要になることはめったにありません（ただし、必要なときに必要なときに物事が混乱し、一部のバイナリでは両方が必要になるため、慎重に再構築する必要があります）。revdep-rebuild.so.libA.so.0libC.so.0libB.so.0libC.so.1libA.so.0libB.so.0

そうは言ってもldd、ダイナミックリンカに実行可能ファイルまたはライブラリを通常どおりにロードさせることですが、途中でいくつかの情報を出力します。これは再帰的な「バイナリニーズライブラリには他のライブラリとヘリが必要」検索です。これは、ダイナミックリンカが行うことだからです。

私は現在Linux/ppc32を実行しています。Linux / x86では、動的リンカーは通常です/lib/ld-linux.so.2。Linux/ x86_64では、動的リンカーは通常/lib/ld-linux-x86-64.so.2です。lddここでは、動的リンカーに魔法を実行するように要求するシェルスクリプトにすぎないという点を強調するために、これを直接呼び出します。

$ /lib/ld.so.1 / sbin / badblocks
使用法：/ sbin / badblocks [-b block_size] [-i input_file] [-o output_file] [-svwnf]
       [-cblocks_at_once] [-d delay_factor_between_reads] [-e max_bad_blocks]
       [-p num_passes] [-t test_pattern [-t test_pattern [...]]]
       デバイス[last_block[first_block]]
$ LD_TRACE_LOADED_OBJECTS = 1 /lib/ld.so.1 / sbin / badblocks
        linux-vdso32.so.1 =>（0x00100000）
        libext2fs.so.2 => /lib/libext2fs.so.2（0x0ffa8000）
        libcom_err.so.2 => /lib/libcom_err.so.2（0x0ff84000）
        libc.so.6 => /lib/libc.so.6（0x0fdfa000）
        libpthread.so.0 => /lib/libpthread.so.0（0x0fdc0000）
        /lib/ld.so.1（0x48000000）
$ LD_TRACE_LOADED_OBJECTS = 1 /lib/ld.so.1 /lib/libcom_err.so.2
        linux-vdso32.so.1 =>（0x00100000）
        libpthread.so.0 => /lib/libpthread.so.0（0x6ffa2000）
        libc.so.6 => /lib/libc.so.6（0x6fe18000）
        /lib/ld.so.1（0x203ba000）
$ grep -l pthread / sbin / badblocks /lib/libcom_err.so.2
/lib/libcom_err.so.2

/sbin/badblocksライブラリの依存関係としてはリストされませんlibpthread.so.0が、によってプルされlibcom_err.so.2ます。

ldd見栄えの良い依存関係ツリーを出力しない問題はありますか？を使用しldd -vます。

$ LD_TRACE_LOADED_OBJECTS = 1 LD_VERBOSE = 1 /lib/ld.so.1 / sbin / badblocks
        linux-vdso32.so.1 =>（0x00100000）
        libext2fs.so.2 => /lib/libext2fs.so.2（0x0ffa8000）
        libcom_err.so.2 => /lib/libcom_err.so.2（0x0ff84000）
        libc.so.6 => /lib/libc.so.6（0x0fdfa000）
        libpthread.so.0 => /lib/libpthread.so.0（0x0fdc0000）
        /lib/ld.so.1（0x201f9000）

        バージョン情報：
        / sbin / badblocks：
                libc.so.6（GLIBC_2.2）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.4）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.1）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.0）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.3.4）=> /lib/libc.so.6
        /lib/libext2fs.so.2：
                libc.so.6（GLIBC_2.1.3）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.4）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.3）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.2）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.1）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.0）=> /lib/libc.so.6
        /lib/libcom_err.so.2：
                ld.so.1（GLIBC_2.3）=> /lib/ld.so.1
                libpthread.so.0（GLIBC_2.1）=> /lib/libpthread.so.0
                libpthread.so.0（GLIBC_2.0）=> /lib/libpthread.so.0
                libc.so.6（GLIBC_2.1.3）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.4）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.1）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.0）=> /lib/libc.so.6
        /lib/libc.so.6：
                ld.so.1（GLIBC_PRIVATE）=> /lib/ld.so.1
                ld.so.1（GLIBC_2.3）=> /lib/ld.so.1
        /lib/libpthread.so.0：
                ld.so.1（GLIBC_2.3）=> /lib/ld.so.1
                ld.so.1（GLIBC_2.1）=> /lib/ld.so.1
                ld.so.1（GLIBC_PRIVATE）=> /lib/ld.so.1
                libc.so.6（GLIBC_2.1.3）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.3.4）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.4）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.1）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.3.2）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.2）=> /lib/libc.so.6
                libc.so.6（GLIBC_PRIVATE）=> /lib/libc.so.6
                libc.so.6（GLIBC_2.0）=> /lib/libc.so.6

必要に応じて、ダイナミックリンカーに依存する代わりにELFヘッダーを直接読み取ることができます。

$ readelf -d / sbin / badblocks | grepが必要です
 0x00000001（必要）共有ライブラリ：[libext2fs.so.2]
 0x00000001（必要）共有ライブラリ：[libcom_err.so.2]
 0x00000001（必要）共有ライブラリ：[libc.so.6]
$ readelf -d /lib/libcom_err.so.2 | grepが必要です
 0x00000001（必要）共有ライブラリ：[libpthread.so.0]
 0x00000001（必要）共有ライブラリ：[libc.so.6]
 0x00000001（必要）共有ライブラリ：[ld.so.1]

のダイナミックリンカーman ld.soで遊ぶことができる他のかわいいトリックもできます。glibc

于 2009-09-29T03:58:01.247 に答える
-2

また、「readelf -d」を提案するつもりでしたが、まだ行っていない場合は、LDFLAGS="-Wl,--as-needed" でビルドするようにしてください。これにより、この問題に遭遇する頻度が低くなります。Portage 2.2 の preserve-libs は素晴らしいですが、主にそれが原因でマスクされていたと思います - 欠陥があります。

于 2012-08-18T07:32:31.147 に答える