私はシステムパッケージのデバッグバージョンをインストールするのが非常に便利なプロジェクト段階にあります。少なくともUbuntuでは、ライブラリにデバッグシンボルを追加するのが冷たいお粥です。ほとんどすべてのパッケージには、有用な-dbgバックトレースに必要なすべてのシンボルを提供するバリエーションがあります。
しかし、私は現在Arch Linuxを使用しています。一般的な合意回避策は、ユーザーmakepkg.confファイルを編集し、デバッグフラグを(C|CXX|CPP|LD)FLAGS。さて、私の考えでは、「ソースベースの展開」には十分に公平ですが、すぐに退屈です。
それでは、システムパッケージにデバッグシンボルを添付する最良の方法は何ですか？他のパッケージング会社はどうなりますか？
stripデバッグシンボルを抽出して外部ファイルに保存することが可能であることがわかります。gdbシステムアプリケーションがファイルを見つけるのに苦労することなく、バックトレース中にこれらのシンボルファイルを選択できますか？包装業者の観点から、これはどのように機能しますか？
これは単なる考えですが、chroot開発環境を作り上げるのは良い考えでしょうか？ （パッケージのデバッグバージョンとリリースバージョンの間にABIの非互換性があるという問題があります。これは少し痛いです。共有ライブラリにリンクされているすべてのエントリも、シンボルの欠落について不平を言うので、最適化されたバージョンに戻ります。）
ベストアンサー1
展開する場合源泉パッケージでは、（autotools）仕様はデフォルトのコンパイルデバッグシンボルです。
私はかつて主流だったLinuxディストリビューションもバイナリに保存したと思います。デバッグシンボルを削除すると、ソフトウェアが「最適化」されるという誤解があります。しかし、実際にはそうではありません。デバッグシンボルを含めることによって生じる唯一の違いは、ファイルがディスクから占めるスペースです。一般的な使用中はメモリにロードされないため、メモリ使用量には影響しません。したがって、他にも影響はありません。削除されたバイナリと削除されていないバイナリを分析します。彼らは同じです。
展開パッケージから分割する目的は、インストールの合計サイズが3.8 GBではなく2.5 GBになるように各パッケージのサイズを小さくすることです。公式リポジトリに含めるパッケージを選択した場合、ディストリビューションはそのパッケージをソースからパッケージ化します。彼らはあらかじめ作成されたパッケージを使用しないので、今これを行う（別々のデバッグパッケージを作成する）ことはその点に影響を与えません。
さまざまなディストリビューションに独立してライブラリバイナリパッケージをデプロイする場合、デバッグシンボルがコンパイルされるかどうかは誰も気にせず、ライブラリを使用してプログラムするほとんどの人はこれを必要とします。何らかの奇妙な理由で苦しむ少数の人々はとにかく簡単に取り除かれます。
したがって、プログラマーであり、Linuxユーザーとして私の意見を聞きたい場合は、少なくとも今はそのままにしてください。 「早期最適化」の明白な焦点、特に実際の最適化ではない早期最適化は、見た目には悪いです。つまり、あなたの質問に対する文字通りの答えは次のとおりです。ベストプラクティス開発中にシステムライブラリにデバッグシンボルを添付する方法は次のとおりです。それらをコンパイル」。
つまり、私は気づいたこのページのWRT .debパッケージ昔は、私が私の信仰を証明しようとしたとき、彼らはいつも含まれていました。タグにdpkgが含まれているため、効果がある可能性があります。