Quote from: jgarzik on July 29, 2010, 11:22:54 PM
Quote from: Odin on July 29, 2010, 11:10:15 PM
Quote from: satoshi on July 29, 2010, 10:17:24 PM
ああ、9.04か9.10のままにしておくべきだったことは痛いほど分かっている。アップグレードよりダウングレードの方がはるかに手間がかかるし、時間に追われている。Ubuntuは最も人気のあるディストロなので、これを使い続ける。
もっともだ。自分が見つけたエンタープライズ版Linuxで動作するBitcoinのバージョンはどれもなかった。エンタープライズLinuxは数年前の古くて信頼性のあるバージョンを使うことが多い。これはUbuntuのLTSシリーズと同等だ。
ディストリビューションは http://releases.ubuntu.com/hardy/ （8.04.4 LTS Hardy Heron）で行った方が良いと思う。どうしてもUbuntuを使うならだが。これはLTSシリーズの_前の_リリースであり、10.4 LTSが18ヶ月経過テストを通過したら、リリースエンジニアリングのリベースを検討してはどうか。
VirtualBoxやXenで2GBの「8.04.4 LTS」ディスクイメージを用意し（ローリングリリース用に限定）、デスクトップ/開発用には好きなバージョンを使い続けることもできるだろう。
そうだ、古いディストロサポートにはqemu/KVMのような仮想マシンが本当にベストな方法だ。
メインの開発マシンを常にフォーマットし直すのはやってられない。
自分のクラウドコンピューティングプロジェクトでは、メインターゲットのLinuxに加えてOpenSolarisとFreeBSDもサポートしなければならない。仮想マシンは救世主だ（そしてコスト節約にもなる）。
「古いディストロサポート用に」という表現から生じうる誤解を解いておきたい。古いディストロでアプリケーションをコンパイルしたからといって、新しいディストロで動作しないわけではない。多くのライブラリはそのように後方互換性がある。
DSOのメジャーバージョンが変更された場合（非互換または破壊的変更）でも、一部のディストリビューションは古い互換ライブラリをインストールする機能を提供している。新しいディストロで古い互換ライブラリを見つける方が、古いディストロで新しいGLIBCを使うよりも容易だ。
私がやや主張したいのは、古いバージョンでコンパイルすることが実際に可能であれば（新しいバージョンが追加する機能がアプリケーションに実際に必要でないため）、そのバージョンを単一のバイナリダウンロードとして提供すべきだということだ（最も幅広い対象者に対応できるから）。
また繰り返すが、OpenSUSE Build Serviceはリモートの仮想化サービスのようなもので、複数の主要ディストリビューションでアプリケーションをコンパイルでき、出力は各ディストロに合わせたパッケージ群となる。
私が見る明確な問題は、補助ライブラリ（Xlib、GTK+、OpenSSL、freetype）のサポートではなく、基本的なGLIBCとGCC libstdc++にある。これの問題は、必要なDLLをbitcoin実行ファイルと同じディレクトリに置いてLD_LIBRARY_PATH（man ld.so）を修正するだけでは済まないことだ。
例えば、選択したディストリビューションで利用可能なものより古いGTK+でコンパイルされた場合（DSOメジャーリリースの変更。これは/usr/lib{,64}/libgtk+-x11-2.0.so.0.1800.9の2番目の「0」で示される。まだゼロであることに注意。これは後方互換性の長期安定性を示す）、ライブラリをインストールせずにLD_LIBRARY_PATHで修正することでこの問題を簡単に解決できる。しかしglibcについては、この方法で問題を解決するのはそう単純ではない。