Quote from: jgarzik on July 30, 2010, 02:05:57 AM
Quote from: Odin on July 30, 2010, 12:24:46 AM Quote from: jgarzik on July 29, 2010, 11:22:54 PM
そうだ、qemu/KVMのような仮想マシンが、古いディストロサポートには本当に一番良い方法だ。
「古いディストロサポート用」という表現による誤解の可能性を念のため。古いディストロでアプリケーションをコンパイルしたからといって、新しいディストロで動かないわけではない。多くのライブラリはその意味で後方互換性がある。
メジャーDSOバージョンが変わる（非互換性のある変更）場合でも、一部のディストリビューションは古い互換ライブラリのインストール機能を提供している。新しいディストロが古い互換ライブラリを見つけるのは、古いディストロが新しいGLIBCを使うよりはるかに簡単だ。
言っていることの大部分は正しいが、bitcoinは依存ライブラリの非常に特定のバージョンに対してビルドされる傾向がある。そのため、基盤となるOSバージョンに関係なく、カスタムコンパイルされたライブラリに対してbitcoinをビルドすることになる。その慣行により、glibcが主要な互換性の懸念事項となる。
具体的にどのライブラリがどの最新glibcバージョンのどの機能を使っているか示してほしい（問題を正しく理解するために）。
見た限りでは、wxWidgetsとboostは静的にリンクされている。「依存ライブラリの非常に特定のバージョンに対してビルド」されるためだろう。しかし、wxWidgetsやboostのどの機能が例えば2.5以上のglibcを必要とするか分からない（2.5もかなり古いが互換性は高い）。wxWidgets 2.9.0やboost 1.40.0をglibc 2.5に対してビルドすることに成功している。
glibcが（あなたの言う）「互換性の懸念」である唯一の理由は、プロジェクトが非常に新しいLinuxシステム上でビルドされたからだ。これによりダウンロードするユーザーは実行するためにビルドシステムと同じくらい新しいLinuxシステムが必要になる。あなたが述べるような本質的な互換性の懸念があるからではない。