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が最も人気のあるディストロなので、これを使い続ける。
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」ディスクイメージを用意し（ローリングリリース用に限定）、デスクトップ/開発用には好きなバージョンを使い続けることもできるだろう。
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もサポートしなければならない。仮想マシンは救世主だ（そしてコスト節約にもなる）。
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については、この方法で問題を解決するのはそう単純ではない。
[Deleted] Quote from: davidonpda on July 29, 2010, 11:40:06 PM
彼にVirtual Boxのコンテナを作ってアップロードするか、ディスクを郵送すればいい。そうすればvboxをインストールして実行するだけだ。
Googleで http://virtualboxes.org/images/ubuntu/ を見つけた。
でもこの場合は不要だと思う。配布リポジトリに配置すればユーザーはパッケージマネージャーでインストールできる。ビルドサービスを使うことでビルドの問題は処理される。
Quote from: Odin on July 30, 2010, 12:24:46 AM
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については、この方法で問題を解決するのはそう単純ではない。 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もサポートしなければならない。仮想マシンは救世主だ（そしてコスト節約にもなる）。
言っていることの大部分は正しいが、bitcoinは依存ライブラリの非常に特定のバージョンに対してビルドされる傾向がある。そのため、基盤となるOSバージョンに関係なく、カスタムコンパイルされたライブラリに対してbitcoinをビルドすることになる。その慣行により、glibcが主要な互換性の懸念事項となる。
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システムが必要になる。あなたが述べるような本質的な互換性の懸念があるからではない。