/usr/lib/.build-id/ dirの目的は何ですか?


10

f27(netinstall)を新しくインストールした後、多くのpkgが小さなファイルを/usr/lib/.build-id/dirに配置していることに気付きました。最初は、どういうわけか、dnfのあいまいな「デバッグ」モードを有効にしたと思いましたが、

$ dnf download httpd

/usr/lib/.build-id/*ファイルを含むw / rpmをフェッチします。

前のFedoraリリースではこれを思い出しません。


rpm --query --file /usr/lib/.build-id「所有」している大量のパッケージのリスト/usr/lib/.build-id...奇妙な。
David Tonhofer

回答:


22

/usr/lib/.build-idインストールされたパッケージのメインのbuild-idファイルが含まれています。Fedora 27以前は、これらはのデバッグファイルと一緒に存在し、/usr/lib/debugデバッグRPMでのみ出荷されていました。Fedora 27では、複数のデバッグ情報パッケージの並行インストールを可能にする変更が導入されました。その変更の一部には、インストールされたバイナリと確実に一致させるために、一致するパッケージ内のメインのbuild-idファイルを出荷することが含まれます。

デバッグ情報パッケージは多くのディストリビューションで使用されており、ユーザーがバイナリを肥大化させることなく、必要なときにデバッグ情報をインストールする方法を提供します。プログラムまたはライブラリーがビルドおよびリンクされると、デバッグ情報を使用してビルドできます。デバッガーは、この情報を使用して、バイナリー内の場所をソースコード内の場所にマップできます。しかし、この情報は多くのスペースを占めます。したがって、デバッグ情報は通常、パッケージ化される前にバイナリから取り除かれます。近年stripobjcopyは、デバッグ情報を個別に抽出して保存できるように拡張されています。これがデバッグ情報パッケージの構築方法です。次に必要なのは、バイナリとそのデバッグ情報が対応していることを確認するいくつかの方法であり、そこにビルドIDが入ります。これらは、ld--build-idそこを探してください)バイナリの重要な部分について。「メインのビルドIDファイル」は、ビルドIDから対応するバイナリファイルまたはデバッグ情報ファイルへのシンボリックリンクです。双方向のマッピングを実装できるため、コアダンプを効果的にデバッグできます(バイナリから、バイナリ自体のビルドIDへのリンクが.gnu_debuglinkセクションにあります)。このすべての背後にある理由の詳細な説明は、Fedora build-id feature descriptionにあります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.