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 については、この方法で問題を解決するのはそう単純ではない。
[Deleted] Quote from: davidonpda on July 29, 2010, 11:40:06 PM
彼にVirtual Boxのコンテナを作ってアップロードするか、ディスクを郵送すればいい。そうすればvboxをインストールして実行するだけだ。
Google で http://virtualboxes.org/images/ubuntu/ を見つけた。
でもこの場合は不要だと思う。配布リポジトリに配置すればユーザーはパッケージマネージャーでインストールできる。ビルドサービスを使うことでビルドの問題は処理される。
ジェフ・ガージックの投稿（2010年7月29日 14: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 でも同じ状況だ。