これは非常に面倒なことだと思います。また、特定のユース ケースを処理するのに問題があるため、機能を「役に立たない」と呼ぶのは傲慢だと思います。 glibc アプローチの最大の問題は、システム ライブラリ (gconv と nss) へのパスがハードコーディングされているため、構築されたものとは異なる Linux ディストリビューションで静的バイナリを実行しようとすると壊れることです。
とにかく、GCONV_PATH を適切な場所を指すように設定することで、gconv の問題を回避できます。これにより、Ubuntu でビルドされたバイナリを取得して、Red Hat で実行することができました。
静的リンクが再び人気を集めています!
- ライナス・トーバルズ は静的リンクをサポートしており、Linux ディストリビューションでの静的リンクの量について懸念を表明しています (このディスカッションも参照してください)。
- 多くの (ほとんど?) 行く プログラミング言語の実行可能ファイルは静的にリンクされています。
- 移植性と下位互換性の向上 人気の理由の 1 つです。
- 他のプログラミング言語にも、静的リンクを非常に簡単にする同様の取り組みがあります。たとえば、次のとおりです。
- ハスケル (私はこの取り組みに取り組んでいます)
- ジグ （詳細はこちら）
- 構成可能な Linux ディストリビューション / NixOS / nixpkgs のようなパッケージ セットを使用すると、パッケージの大部分を静的にリンクできます (たとえば、その
pkgsStaticパッケージ セットは、あらゆる種類の静的にリンクされた実行可能ファイルを提供できます)。 - 静的リンクにより、未使用コードの排除が向上する可能性があります リンク時に、実行可能ファイルを小さくします。
- musl のような libcs 静的リンクを簡単かつ正確にする
- いくつかの大きなソフトウェア業界 リーダーはこれに同意します。たとえば、Google は静的リンクを対象とした新しい libc を作成しています (「静的非 PIE および静的 PIE リンクをサポート」 、「現時点では動的読み込みとリンクのサポートに投資するつもりはありません」 ).
<ブロック引用>
その事実に関して、Linux で完全に機能する静的ビルドを作成する合理的な方法はありますか?それとも、静的リンクは Linux で完全に機能していませんか?
歴史的な参照がどこにあるのかわかりませんが、そうです、静的リンクは GNU システムでは死んでいます。 (libc4/libc5 から libc6/glibc 2.x への移行中に死んだと思います。)
この機能は、次の点で役に立たないと判断されました:
-
セキュリティの脆弱性。静的にリンクされたアプリケーションは、libc のアップグレードもサポートしていません。 lib の脆弱性を含むシステムでアプリがリンクされた場合、静的にリンクされた実行可能ファイル内で永続化されます。
-
コードの肥大化。多くの静的にリンクされたアプリケーションが同じシステムで実行されている場合、標準ライブラリは再利用されません。これは、すべてのアプリケーションが独自のすべてのコピーを内部に含んでいるためです。 (
du -sh /usr/libを試してください 問題の範囲を理解するためです。)
10 ～ 15 年前の LKML と glibc メーリング リストのアーカイブを掘り下げてみてください。ずっと前に LKML に関連するものを見たことがあります。