glibcのバイナリビルドをインストールする簡単な方法はありますか?


13

次のような質問が何度もあります。

そして、これらは私たちが通常推進しているタイプのソリューションです:

これは本当にできることですか?GLIBCのバイナリビルドがあり、のようなディレクトリに単純に解凍し、何でも/opt/myglibc設定して、$LD_LIBRARY_PATH問題なくアプリケーションを実行できますか?

GLIBC 2.14を必要とするChrome(28以降)の新しいビルドなどのアプリケーション

注:Google Chrome 29リリース-tecmint.comのRHEL / CentOS 6およびFedora 19/15インストール」というタイトルのスレッドは、最終的にこのことについて考えさせられたものです。

参照資料

回答:


1

それが他のライブラリ用であるが、glibcの場合... glibcはものが「ハードコード」されている場所であるため、迅速な方法はないと思います。glibcはカーネルのバージョンに適合し、ローダーは実際に正しいこと(TM)を行うインスタンスですLD_LIBRARY_PATH

たぶん正しい方法は:

LD_LIBRARY_PATH="/opt/myglibc/;..." /opt/myglibc/ld-linux.so.2 the_program`

ただし、これが機能するかどうかはわかりません。

とにかく、代替のglibcを使用するには、まだフレームワークを実装する必要があります。検索パスは時々配線され、glibcは常にOS /カーネルに適合する必要があるため、汎用バイナリIMOは存在できないからです。Debianのマルチアーチは、些細なことではないことを示していますが、それでも実行できます。ターゲットアーキテクチャ以外にライブラリを識別する他の手段がある場合。

ウェブサイトはこの他の関連するスレッドを私に与えました:

そこで、受け入れられた答えには、glibcの問題を解決していると思われるrtldiと呼ばれるプログラムへのリンクが含まれています。2004年からですので、リンカからすぐには動作しないかもしれませんが、検討する価値があるかもしれません。そのソースはGPLv2です。

エホバ、エホバ

私の友人は、共有ライブラリの実際の使用が過大評価されているという考えを思いつきました。そして、彼はポイントを持っています:共有ライブラリは、コンピューターのメモリを重複でいっぱいにしないのが良いですが、個々のアプリケーションインスタンスを考慮すると、これはほんの数MBです。

独自のglibcを提供するなどのアクションに頼るアプリケーションはわずかです。長い分析を省いて、それらを「即時アプリケーション」と呼びましょう。それは、仕事を成し遂げるという意味で、それ自体で役立ちます。たとえば、Webブラウザー、メールユーザーエージェント、オフィススーツ、音楽プレーヤーを使用すると、ユーザーは必要なものを取得できます。ユーザーごとのインスタンスはわずかです。反対側をポートレートするには、システムサービス、ウィンドウマネージャー、デスクトップ環境全体がすべて非常に重要ですが、単にサポートしているだけで、あまり一般的でも重要でもないため、人々は自分のglibcを喜んで提供します。

「即時アプリケーション」の数はかなり少なく、ユーザーごとに絶対であり、最近の「基本的な」OSおよびDEが生成するものと比較して比較的少ないです。Chrome、Firefoxなどの直接的なアプリケーションが静的にコンパイルされた場合、平均的なシステムの追加メモリ要件は数100MBになります。現在の多くのGBシステムではあまり有効ではない引数なので、即時アプリケーションの静的リンクはオプションです。

スワップスペースとSSDの概念もあり、これは途方もなく高速なスワップイン/アウトを可能にし、増加するメモリ要件の処理にも役立ちます。

ここで説明したglibcの問題は、静的リンクを介しても実際には解決されませんが、Webブラウザーなどのアプリケーションでは、Xプロトコル、サウンドデーモン、カーネルMeethodsが唯一のインターフェイスであるような自己完結型の配布形式が考えられます。利点は、ライブラリバージョンの非互換性が少なくなることです。


2
「我々はここ数百メガバイトの話をしている」ええと、ありません。 ライブラリ自体の大部分はそれほど大きくないかもしれませんが(ただし、おそらく1桁または100 MBを超える2つ-try du -h /lib)、それらが静的にコンパイルされた場合、それぞれの量のRAMが必要になることに注意してくださいそして、それらでコンパイルされたすべてのアプリケーション。 たとえば、同じライブラリスタックを使用する2つのアプリがある場合、2倍のメモリが必要になります。3つのアプリ?3倍。言うまでもなく、キャッシングの利点はほとんど無効になります
...-goldilocks

2
...もちろん、glibcをキャッシュすることはできませんでした-実行されているすべてのアプリケーションのコピーをキャッシュする必要があります(==ばかげています)。要するに、最新のハードウェアでは、共有オブジェクトなどの最新の技術を使用しなければ、最新のオペレーティングシステムはまったく単純であり、まったく不可能です。もう少しメモリは必要ありません。10倍または100倍のメモリが必要です。
goldilocks

私のDebianには235MBが/libあり、そのうち202MBはカーネルモジュールです。はい、/usr/lib4GBですが、個々のプログラムに必要な量について正確に結論付けることはできません。プロセッサのキャッシュはわずか数MBです。最近のWebブラウザーのようなもののメモリ消費により、静的にリンクされたバイナリーのキャッシュへの影響もそれほど大きくなく、同時に実行されるプログラムの量とともに減少します。また、キャッシュが比較的小さいためです。私の見積もりはあなたの見積もりよりも正確に見えます。ええ、はい。
バナンギン

静的リンクに関する他の大きな問題は言うまでもありません。更新はPITAです。glibcにセキュリティ上の問題がある場合、大したことはありません。glibcをアップグレードし、プログラムを再起動してください。OTOH、プログラムは静的にリンクされていたので、すべてのプログラムの新しいバージョンをダウンロードする必要があります。そして、あなたのディストリビューションは、ディストリビューション全体を再コンパイルする必要があります(または、すべての.oファイルを保持している場合は、少なくとも再リンクする必要があります)。
デロバート

1
@derobert:公平そうです。明らかに私の主張は双曲的でした-ここでは1.8 GBで521 MBを吐き出しました。そのため、30%増加します。もちろん、それはまだ利点のない戦略のセールスポイントではありません(ただし、「30%以上のRAMしか必要ありません」)。
goldilocks
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.