Linuxディストリビューションのダウンロード
こんにちは、
私はソフトウェア開発者で、Linuxでのビルドには詳しいが、ほかの人たちがもっと楽にできるよう、いくつかヒントを出そうと思った。
動的リンクしたLinux向けの単一のダウンロードパッケージを配布するときに、一つ大事な点がある。「使える最も古いバージョンのglibc/libstdc++を使うべきだ。つまり、新しい機能やバグ修正が必要だと分かっていないかぎり、実行時のライブラリはもっと新しく、それらの修正を含んでいるものと考えてほしい。」
最新版のglibc/libstdc++にリンクすることの問題は、（これらのバイナリを動かすために）ユーザーにも最新のシステムを強いてしまう点だ。特別な理由がないかぎり、それを必須の前提にすべきではない。そういう理由があるなら、ドキュメントで説明すべきだ。古いシステムで普通にリンクすれば、その古いシステムでも最新のシステムでも動く。
特定の新しいGCC最適化が本当に必要なCコードの部分があるなら、最新のGCCで一度生成したASMのダンプファイル（*.s）を用意してソースに含め、誰でも（古いGCCでも）コンパイルできるようにすることを考えてほしい。
いくつか勧めておく：
- バイナリのビルドには、使える最も古いベースのディストリビューションを使う。たとえば、今のDebianリリースの最新のコピーではなく、_前回_のDebianリリースの最新のコピーだ。
- 静的バイナリを含むダウンロードを用意する（リンク時に
-staticオプションを使い、実行ファイル名をbitcoind-staticのようにするといい）。これは別のダウンロードファイルにする。 - ソースディストリビューションのビルドが、必要なライブラリの作業用コピーから動くようにする。特にboostとwxWidgetsで、ビルドにとても新しいバージョンが必要だと分かっているなら、それぞれのビルドツリーから直接ビルドとリンクができるようにする（インストールしなくて済むように）。/usr/localへのインストールは問題になりうる（私にとっては確実に問題だ）が、ビットコイン専用にカレントディレクトリに置くのは問題ない。結局、ビットコインがビルドに必要なのはヘッダーファイルとDSOか*.aへのアクセスで、実行時に必要なのはDSOへのアクセスだ。
24時間365日動くヘッドレスのbitcoindを立ち上げることはできるが、これらの問題のせいで、解決する時間を見つける/作るまでは、今のところできない。
自分の投稿に返信して申し訳ない。
1つの解決策として、OpenSUSE OBSプラットフォームhttp://wiki.meego.com/Build_Infrastructureにプロジェクトを作成することが考えられる。
このプラットフォームは誰でも使える自動ビルダーだ（自分のアカウントとホームエリアを作成することで）。
プロジェクトと*.spec（ビルド記述子）をアップロードすれば、主要なLinuxディストリビューション（OpenSUSE、CentOS/RHEL、Fedora、Ubuntu、……）すべてのフォーマットでビルドしてくれる。個別にメンテナンスする必要がなく、自動で行ってくれる。
結果は*.debや*.rpmなど、プラットフォームに応じたパッケージになる。
ええ、9.04か9.10に留まるべきだったと痛感している。ダウングレードはアップグレードよりもずっと手間がかかるし、時間に追われている。Ubuntuが最も人気のあるディストロなので、これを使い続ける。
ええ、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」ディスクイメージを用意し（ローリングリリース用に限定）、デスクトップ/開発用には好きなバージョンを使い続けることもできるだろう。
VirtualBoxやXenで2GBの「8.04.4 LTS」ディスクイメージを用意し（ローリングリリース用に限定）、デスクトップ/開発用には好きなバージョンを使い続けることもできるだろう。
そうだ、古いディストロサポートにはqemu/KVMのような仮想マシンが本当にベストな方法だ。
メインの開発マシンを常にフォーマットし直すのはやってられない 😊
自分のクラウドコンピューティングプロジェクトでは、メインターゲットのLinuxに加えてOpenSolarisとFreeBSDもサポートしなければならない。仮想マシンは救世主だ（そしてコスト節約にもなる）。
そうだ、古いディストロサポートにはqemu/KVMのような仮想マシンが本当にベストな方法だ。
「古いディストロサポート用に」という表現から生じうる誤解を解いておきたい。古いディストロでアプリケーションをコンパイルしたからといって、新しいディストロで動作しないわけではない。多くのライブラリはそのように後方互換性がある。
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については、この方法で問題を解決するのはそう単純ではない。
[削除済み] Quote from: davidonpda on July 29, 2010, 11:40:06 PM
彼にVirtual Boxのコンテナを作ってアップロードするか、ディスクを郵送すればいい。そうすればvboxをインストールして実行するだけだ。
Googleでhttp://virtualboxes.org/images/ubuntu/ を見つけた。
3番目の項目、http://downloads.sourceforge.net/virtualboximage/ubuntu-8.04-x86.7zを試すといいかもしれない（505Mbのダウンロードで、解凍後は2.67Gbのイメージになる）。
ジェフ・ガージックの投稿（2010年7月29日23:22 UTC）そうだ、古いディストロサポートにはqemu/KVMのような仮想マシンが本当にベストな方法だ。
「古いディストロサポート用に」という表現から生じうる誤解を解いておきたい。古いディストロでアプリケーションをコンパイルしたからといって、新しいディストロで動作しないわけではない。多くのライブラリはそのように後方互換性がある。
DSOのメジャーバージョンが変更された場合（非互換または破壊的変更）でも、一部のディストリビューションは古い互換ライブラリをインストールする機能を提供している。新しいディストロで古い互換ライブラリを見つける方が、古いディストロで新しいGLIBCを使うよりも容易だ。
言っていることの大部分は正しいが、bitcoinは依存ライブラリの非常に特定のバージョンに対してビルドされる傾向がある。そのため、基盤となるOSバージョンに関係なく、カスタムコンパイルされたライブラリに対してbitcoinをビルドすることになる。その慣行により、glibcが主要な互換性の懸念事項となる。
言っていることの大部分は正しいが、bitcoinは依存ライブラリの非常に特定のバージョンに対してビルドされる傾向がある。そのため、基盤となるOSバージョンに関係なく、カスタムコンパイルされたライブラリに対してbitcoinをビルドすることになる。その慣行により、glibcが主要な互換性の懸念事項となる。
具体的にどのライブラリがどの最新glibcバージョンのどの機能を使っているか示してほしい（問題を正しく理解するために）。
見た限りでは、wxWidgetsとboostは静的にリンクされている。「依存ライブラリの非常に特定のバージョンに対してビルド」されるためだろう。だが、これらのライブラリのどちらも新しいglibcを必要とする理由が見当たらない。wxWidgetsは ./configureの段階でglibc 2.1以降を要求する程度の確認しかしていない。wxWidgets 2.9.0やboost 1.40.0のどの機能が、例えばglibc 2.5以上 (これもかなり古いが互換性は高い) を必要とするのかは判然としない。実際、私はこれらの版 (wxWidgets/boost) をglibc 2.5に対してビルドできている。
これはsrc/makefile.unixの中で -Bstaticが使われていることでも確認できると思う。
glibcが（あなたの言う）「互換性の懸念」である唯一の理由は、プロジェクトが非常に新しいLinuxシステム上でビルドされたからだ。これによりダウンロードするユーザーは実行するためにビルドシステムと同じくらい新しいLinuxシステムが必要になる。あなたが述べるような本質的な互換性の懸念があるからではない。
OpenSUSEビルドサービス (OBS) 上でwxWidgets 2.9.xのカスタムビルドは作れたと思う。ここ数時間のうちに、うまくいくならboostも試してみる。それが済めばbitcoindパッケージをコミットしてopenSUSE用ビルドを取得し、その先で他のディストリビューションのリポジトリ (CentOS, Ubuntu, SLE, Fedora等) も有効化できる。
boostは「1.40.0」が必要なのか、「1.40.0以降」でよいのか、誰か確認してもらえないだろうか。現行は1.42.xで、複数の環境向けにすでにパッケージとして用意されている。この経緯を説明してくれる人はいないかな。
wxWidgets 2.9.xは開発系列なのでプレリリースだ。プレリリース版を使うためにカスタムビルドが必要なのは当然で、これはOBSビルドで解決済みだ。
CentOS x64上のbitcoin 0.3.6a
[foo@bar ~]$ bitcoin-0.3.6/bin/64/bitcoind
bitcoin-0.3.6/bin/64/bitcoind: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.9' not found (required by bitcoin-0.3.6/bin/64/bitcoind) bitcoin-0.3.6/bin/64/bitcoind: /lib64/libc.so.6: version GLIBC_2.7’ not found (required by bitcoin-0.3.6/bin/64/bitcoind)
x32でも同じ状況だ。