Linuxで静的ライブラリと共有ライブラリの作成と使用を理解しようとしています。図書館案内。リンクに私が混乱している2つの文があります。
- 静的ライブラリを使用すると、ユーザーはコードを再コンパイルすることなくプログラムに接続できるため、再コンパイル時間を節約できます。
- 静的ライブラリは、プログラマが自分のライブラリにリンクすることを可能にしますが、ライブラリのソースコードを提供したくない開発者にとって便利です。
1関連：静的ライブラリは実行可能ファイルの一部で終わり、共有ライブラリは独立して保持され、実行可能ファイルが実行を開始したときにのみロードされます。しかし、両方のライブラリが新しいアプリケーションでライブラリを使用しようとしたときに再コンパイルする必要がないという利点はありますか？ライブラリ自体が変更されないと仮定すると？これが本当なら、なぜこのステートメントは共有ライブラリと比較して静的ライブラリの利点があるという印象を与えますか？
2について: 繰り返しますが、これは共有ライブラリには適用されませんか？共有ライブラリは、アーキテクチャ固有の形式のPICで生成されますが、オブジェクトファイルも使用します。それでは、この場合、ソースコードは共有されますか？
答え1
私は図書館の外部知識を想定せずに提示された順序でガイドを理解する必要があると思います。したがって、第2章「静的ライブラリ」、比較には共有ライブラリは含まれておらず、まだ導入されていません。
したがって、両方の抜粋はソースコードとの比較にすぎません。ソースコードを提供するよりも静的ライブラリを構築することで、ソースコードを再コンパイルしたり提供しなくても、コンパイルされたオブジェクトを再利用できます。
答え2
抜粋内容が不明です。
静的ライブラリは実行可能ファイルの一部になり、その実行可能ファイルの外部では使用できません。望むよりman ld。これは外部機能と同じように扱われます。静的にリンクされた実行可能ファイルは、動的にリンクされた実行可能ファイルよりも大きいが完全です。自給自足です。
ダイナミックリンクライブラリを使用すると、プログラムはライブラリ名を提供します。必要なバージョンなどのman elf readelf
プログラムがロードされるとld.so（参照）、man ld.soダイナミックリンクライブラリがタスクのメモリにマッピングされ（参照man mmap）、プログラムがライブラリにアクセスできるように間接呼び出しテーブルが設定されます。ダイナミックリンクライブラリを使用すると、システムはすべてのタスク間でRAMのライブラリコピーを共有できます。動的ライブラリを使用すると、実行可能ファイルが小さくなり、ライブラリの更新がシステム管理者に委任されます。ただし、必要なライブラリとバージョンが利用できない場合は、実行時にライブラリの検証が失敗する可能性があります。彼らは完全でも自給自足でもありません。