Cの静的ライブラリは眉をひそめていますか？[閉まっている]

共有ライブラリを持つための2つの引数があります。

1. ディスク容量を削減するのに役立ちます。
2. 共有ライブラリが更新されると、それに依存するすべてのバイナリが更新を取得します。

共有ライブラリには主に1つの欠点があります。

• 彼らは依存性地獄を導入することができます。

デスクトップコンピューターでは、第1の利点はもはや成り立ちません。最近では、ディスク容量の無駄遣いはあまり問題になりません。

静的バイナリを使用すると、パッケージマネージャーの質が向上します。つまり、依存関係の地獄は過去のものになります。プログラムを追加すると、単にバイナリが追加されます。最終的には、ファイルを処理するためのフォルダー。プログラムを削除すると、単にこのファイルが削除されます。依存関係？消えた。

2番目の利点はまだありますが、デスクトップコンピューター上の静的バイナリの利点はそれよりも重要だと思います。つまり、Goのような新しい言語でさえ、共有ライブラリの利点にもかかわらず、すべてのバイナリをコンパイルします。これは利便性のためです。

共有ライブラリの主な利点の1つはもはや大したことではないので、Cの静的ライブラリはまだ嫌われていますか？もしそうなら、なぜですか？

あなたの質問の前提には欠陥があります。眉をひそめているのは、それらの背後にある基礎を理解せずに教義と絶対主義に固執していることです（カーゴカルトプログラミング？）。

リンクされたSOの答えは非常にトピックに関する興味深い研究です-質問は-staticオプションを使用してコンパイルが機能しない理由に関するものであり、リンクした答えは静的リンクを使用しないことに関する暴言に過ぎませんでした。Ifがなぜ悪いかについて議論せず、OPが動的リンクを使用することを要求します。残念なことに、正解としてマークされています（次の回答は投票数が2倍で、OPの質問に対する正解です）。正解はそこにありますが、独断的な意見の中に深く隠されているからです。

本当の問題は、静的リンクと動的リンクの長所と短所は何か、いつどちらが優先されるかです。

開発者の観点から見ると、動的リンクは多くの場合、コンパイル/リンク/テストループを大幅に高速化します。

パッケージ管理の観点から、たとえばlibGLを取り上げます。パッケージマネージャーでは、約12種類の実装を利用できます。一部は汎用、一部は特定のグラフィックカードを対象としています。動的にリンクされていなかった場合、libGLとリンクする各プログラムのダースバージョンが必要になります。さもなければ、関数呼び出しほど効率的ではない抽象化の追加レイヤーを考案する必要があります。

Qtのような一般的なライブラリのセキュリティ問題を考えてください。動的リンクを使用すると、Qtでリンクするすべてのパッケージを識別、再コンパイル、デプロイする代わりに、その1つのパッケージを更新するだけで済みます。

静的リンクは、独立して展開されたクローズドソースアプリケーションでは利点があるかもしれませんが、オープンソースパッケージ管理では、役立つ以上の害をもたらします。

基本的にあなたの理由＃2のため、Linuxディストリビューションのメンテナーは共有ライブラリを強く推奨します。たとえば、zlibでセキュリティバグを見つけた場合、zlibを使用するプログラムを1つずつ再コンパイルする必要がないことは非常に重要です。再コンパイルすると、ディストリビューションを使用するすべてのユーザーは、それらのプログラムをすべて再ダウンロードする必要があります。その間、ディストリビューションによって提供されるパッケージのセット内では、すべてがライブラリのセットで動作するようにテストされているため、依存関係の地獄は問題になりません。

ディストリビューションにないライブラリを必要とするサードパーティのソフトウェアを構築している場合、それらのライブラリを静的にリンクすることは、他のライブラリよりも手間がかからない可能性があります。

他に知っておくべき重要なことは、GNU libcとGCCのlibstdc++両方に、ライブラリが静的にリンクされていると確実に動作しないコンポーネントがあることです。最も一般的な問題は、dlopenロードするモジュールdlopen自体が動的にリンクされるためlibc.so.6です。つまり、アドレス空間にCライブラリの2つのコピーが存在することになり、内部mallocデータ構造のコピー（たとえば）が信頼できるかどうかについて同意が得られない場合は、喜びが続きます。何かを持っているように見えない関数の全体の束を：それは悪くなるdlopenように、gethostbynameそしてiconv、使用dlopen内部的に（その動作が実行時設定可能になるように）。幸いなことに、libcとlibstdc ++のABIは非常に安定しているため、それらを動的にリンクする際に問題が発生することはほとんどありません。

mattnzの最後の点に同意します。この質問は、ロードされた質問です。静的リンクが悪いと仮定します。これが当てはまらない2つの理由を考えることができます。

• 静的リンクは安全です：アプリケーションが新しいライブラリを使用するように共有ライブラリが更新された場合（新しいライブラリが古いライブラリを上書きするか、古いライブラリが削除される可能性があります）、新しいバージョンがアプリケーションを破壊するリスクが生じる可能性があります。これは、アプリケーションの公式アップデートの範囲外のコード変更です。テストされていない可能性があります。静的リンクは、ライブラリを外部で共有しないことでこれを回避します。このリスクのため、これは共有ライブラリにとって不利だと思います。共有ライブラリの新しいバージョンが特定の古いアプリケーションを破壊する新しいバグを導入した場合はどうなりますか？

• 静的リンクにより、アプリケーションはより自己完結型になります。共有ライブラリはプライマリ実行可能ファイルと同じ場所に配置できますが、多くの場合、共有ライブラリに配置されます。静的にリンクされたアプリケーションは、「OSが所有するファイル、ディレクトリ、または設定の変更を必要としない」という意味で「ポータブル」を保証するのが簡単です（Windowsディレクトリ、レジストリ、/ etcを考えてください）。

静的ライブラリと動的ライブラリにはそれぞれ独自の用途があります。スコープ内の単一のアプリケーションを見ると、必要なものとそうでないものについて異なる考えが得られます。

静的リンクは、アプリケーションの展開を大幅に簡素化します。異なるバージョンを検出して対処する必要はありません。焼いて展開するだけです。

動的ライブラリの明らかな利点は、更新を個別に適用できることです。

これが、私がMavenやその他のJava用のダイナミックリンクプロジェクトビルダーを嫌う理由の1つです。彼らは、特定のURLで単一のライブラリバージョンがいつまでも利用できることを期待しています。すべてのソースとjarがなくなったために、誰もアプリケーションをコンパイルできない10年後に発生する問題を理解していません。