私のLinuxバイナリはすべてのディストリビューションで動作しますか？
私は良い代替品を見つけましたIDE Lazarusと呼ばれるDelphiのです。しかし、プログラマには質問がありません。
静的にリンク LinuxバイナリはすべてのLinuxディストリビューションで機能しますか？つまりビルドしたLinuxディストリビューションに関係なく、Debian/ArchLinux/Ubuntu/OpenSUSE/...何でも動作しますか？
私の調査結果の結果、本当に問題になるのは32ビットと64ビットのどちらですか。公開する前に確認したい。
この回答は、最初に「一般的なバイナリはすべてのディストリビューションで実行されますか？」というより一般的な質問に対して書かれましたが、後半で静的にリンクされたバイナリを扱います。
静的にリンクされたhello worldよりも複雑なものの場合、答えはおそらくnoです。
ディストリビューションXでテストせずに、Xの答えisnoと仮定します。
ソフトウェアをバイナリ形式で出荷したい場合は、
ソフトウェアの使用分野で人気のあるディストリビューション（デスクトップ、サーバー、組み込みなど）
それぞれの最新の1つまたは2つのバージョン
それ以外の場合は、すべてのサイズ、バージョン、および年齢の数百の配布になってしまいます（10歳の配布がまだ使用されていますおよびがサポートされています）。
それらをテストします。さもなければ、何がうまくいかず、何がうまくいかないかについてのほんの少しのポインタ：
必要なツール/ライブラリのパッケージの名前は、ディストリビューションによって異なり、同じディストリビューションのバージョンでも異なる
必要なライブラリが古すぎるか、古すぎます（バージョンが間違っています）。プログラムがリンクできるからといって、正しいライブラリとリンクしないと思い込まないでください。
同じライブラリ（ディスク上のファイル）は、ディストリビューションごとに異なる名前が付けられているため、リンクできません
64ビット上の32ビット：32ビット環境がインストールされていないか、一部の必須でない32ビットライブラリが32on64環境とは別の追加パッケージに移動されているため、この場合にのみ追加の依存関係があります。
シェル：Bashのバージョンを想定しないでください。バッシュすら想定しないでください。
ツール：POSIX以外のコマンドラインツールがどこかにあると想定しないでください。
ツール：GNUあなたのディストリビューションのバージョンがそうするからといって、ツールがオプションを認識すると仮定しないでください。
カーネルインターフェイス：_
/proc_内のファイルの存在または構造を前提としないでください。ファイルがマシン上に存在する/構造を持っているからです。Java：プログラムをSLESに同梱されているIBMのJREでテストせずに実行しますか？
ボーナス：
- 命令セット：マシンでコンパイルされたバイナリは、古いハードウェアでは実行できません。
静的にリンクする（または：ソフトウェアに必要なすべてのライブラリをバンドルする）ソリューションですか？たとえそれが技術的に機能しても、関連するコストは高くなる可能性があります。だから残念ながら、答えもおそらくノーです。
セキュリティ：ライブラリを更新する責任をソフトウェアのユーザーから自分に移します。
サイズと複雑さ：楽しみのために、静的にリンクされたGUIプログラムを作成してみてください。
相互運用性：ソフトウェアがあらゆる種類の「プラグイン」である場合、呼び出し元のソフトウェアに依存します。
ライブラリの設計：プログラムをGNU libcに静的にリンクし、ネームサービス（
getpwnam()など）を使用する場合、libcのNSS（ネームサービススイッチ）に対して動的にリンクされます。ライブラリの設計：プログラムを静的にリンクするライブラリは、データファイルまたは他のリソース（タイムゾーンやロケールなど）を使用します。
上記のすべての理由により、テストが不可欠です。
KVMまたはその他の仮想化手法に精通し、サポートするすべてのディストリビューションのVMを用意します。すべてのVMでソフトウェアをテストします。
それらのディストリビューションの最小限のインストールを使用してください。
制限された命令セットを使用してVMを作成します（例：SSE 4））。
静的にリンクまたはバンドルのみ：
lddを使用してバイナリを確認し、それらが本当に静的にリンクされているかどうか、バンドルされているライブラリのみを使用しているかどうかを確認します。静的リンクまたはバンドルのみ：空のディレクトリを作成し、そこにソフトウェアをコピーします。
chrootをそのディレクトリに入れ、ソフトウェアを実行します。
答えは状況によって異なりますですが、必要なライブラリがOSにインストールされている限り、ほとんどの場合はい。
一般的に、あなたが言及したようなほとんどの主要なディストリビューションには、コミュニティー管理バージョンのアプリケーションをインストールするパッケージ管理ツールがあります。これにより、アプリケーションが必要とするすべての必須パッケージが処理されます。パッケージマネージャーなしでインストールする場合は、必要なすべてのパッケージとライブラリがOSにインストールされていることを確認する必要があります。これらの必須アプリケーションのリストをドキュメントに含めることをお勧めします。
最初は奇抜な答え：
バイナリをリリースする場合は、そのライブラリallを配布する場合でない限り、答えは「いいえ」であると想定します。 everはこれに関係するか（ゼロから始めて、とにかくそれ自体で独立した非常に巨大なシステムを提供しない限り、これは厄介です）、または同等のものを静的にリンクしています。
...しかし魔法使いとお金、そしてお金の魔法使い...
IBMにはいくつかの「一般的なUnix風」のインストーラーがあり、私が試したことのあるあらゆる場所で作業することでショックを受けました。いくつかのカーネル世代のいくつかのLinuces、OpenSolaris（または現在呼ばれているもの）、Solaris、およびBSDです。しかし、それらは巨大です。そして、彼らが提供するものも同様に巨大です。このようにすばらしく小さなレースカープログラムが公開されることはありません。IBMに期待する大企業向けのものだけです。
Linuxにとどまる限り、ほとんどのLinuxdomで正常に機能する限り、これはバイナリ形式で可能であるように見えます。これは、一部のベンダーから見られるさまざまな「Linux（一般）」タイプのバイナリインストーラーによって証明されています。いくつかのチャット、ブラウザ、ゲーム、メタインストーラなどがこの方法で公開されていますが、常にこれを正しく行うために時間を費やすことができる巨大なベンダーによって常に行われています。彼らが「Linuxの場合」と言って、それが機能することを一般に確信できるのは、一種の驚くべきことですが、これは事実のようです。
しかし...
ビルドユーティリティを使用して、ソフトウェアをソースとして配布しています。私はC、Erlang、Python、Guileなどでこれを実行します。これにより、実行するかどうかについてlotより多くの柔軟性が得られます。実行時にすべてが適切であることを確認するよりも、ビルド時に適切なものが存在することを確認するビルドスクリプトを書く方がはるかに簡単です。それが存在すると、ソースを配布する場合、プログラムの自動更新プログラムを作成するのは簡単です。通常、ソースは、すべてのdepやその他の狂気を含むバイナリよりもはるかに小さくなります。この方法を使用すると、Unice全体（場合によってはWindowsですが、少し面倒な作業）に確実に展開するのにそれほど問題はありませんでした。
十分なチャイルドプレイ、腕を組んでください！
Srsly srsのように、Linuxの世界にスムーズに適合することについて真剣に取り組んでいるときは、Cソースを配布するかまたは完全に管理された環境に切り替えて、ハッカのように楽しいあらかじめ作成されている言語。たとえば、Pythonコードを記述している場合は、バージョンを確認して、使用するCPythonバージョンを確認できます。また、特定のLinuxに互換性のあるバージョンが存在することを期待できます（これははるかに簡単です）使用している可能性のあるCライブラリ/バージョンの広範なスイープよりも確認してください。Erlang、Guile、Python、Perl、CLなどはすべてveryこの種のデプロイメントの簡単なターゲットであり、それらの多くはCPANやpip（またはその他）などの中央リポジトリーを備えており、ユーザーはコマンドを実行して必要なときに署名付きソースを自分でプルし、通常は意図したとおりに機能することを知っています。 。
[補遺：1.通常、HaskellでもCabalを使用してこれを実行できます-実稼働環境での実行には注意が必要です。 2. Erlangを使用した完全に異なる「リリース」デプロイメント戦略があり、コードがそれを取り巻く完全な環境を運ぶことを保証します。 3. Pythonは仮想環境を一歩前進させます。すべてのランタイムがあなたを助けるわけではありません。]
Linuxの管理環境に関するこの最後の部分は、すごいです。さらに、おまけとして、より一般的な依存関係を定義し、追加の作業なしで自動的に解決することができ、ディストリビューションごとにパッケージを作成する必要がありません。システムが32ビットか64ビットか（通常、とにかく）を気にしないでください。