まず、似たような質問を見つけましたポータブル Linux アプリを作成するにはどうすればよいでしょうか?しかし、これは私の質問に実際に答えているわけではなく、アプリケーションを移植可能にするためにコンパイルする方法に関するもので、その方法は既に知っています (少なくとも私は知っています)。以下で説明するように、デプロイメントに関するものではありません。
これが私の状況です。私たちは、クライアントの特定の問題を解決するために雇われ、クローズド ソース アプリケーションを開発して、クライアントに販売する予定です。ただし、どこで実行できるか、つまりディストリビューションやカーネル バージョンなど、具体的なことは何も知らされていません。タスクはかなり単純で、低レベルのドライバーや、移植性を複雑にするようなものに依存しません。ただし、いくつかのサード パーティ ライブラリに依存しています。以下は、依存関係の簡単なスキームです。
app --+-- libA
| +-- lib1
+-- libB --+-- lib2
+-- lib3
ここで、libA、B、lib1、2、3 はすべて適切なライセンス (LGPL、ASL、BSD) を持つオープンソース プロジェクトです。コンパイルされると、プログラムの共有依存関係は libA、libB、lib1、lib2、lib3 と、libc、libm、libz、libstdc++、libpthread などの一連のシステム ライブラリになります。すべてが動的にリンクされます。
現在、ターゲット ディストリビューションがないため、.deb などのパッケージ システムから独立させておきたいと考えています。直接の依存関係 (libA と libB) はあまり一般的ではないため、当然の選択は、これらをアプリケーションと一緒に配布することです。lib1、2、3 は実際にはより一般的ですが (つまり、そのうちの 1 つは libpng)、ターゲット システムにインストールされるかどうかはまだわかりません。最終的なソフトウェア パッケージには、これら 5 つすべてを含めることにしました。
私たちには、システム ライブラリについてはどうしたらよいかわかりません。これをどう処理すればよいのでしょうか。正しいライブラリが用意されていると仮定して、うまくいくように祈るだけでよいのでしょうか。そのような場合、1 年か 2 年後にライブラリの 1 つが変更され、アプリケーションが動作しなくなったらどうなるのでしょうか。
これらすべて (libstdc++、glibc など) をソフトウェアと一緒に配布すべきでしょうか? これは正しいとは思えませんし、ライセンス条項に違反しているのではないかと思います。過去に、それらのライブラリの [少なくとも] 一部を独自にコピーしたプログラムを使用したことがありますが、それが私のシステムにあるものよりも古いバージョンだったため、それらを交換するとすべてが機能しなくなる (偶然に気付いた) ため、実際に注目しました。
これは通常どのように処理されますか?
答え1
Linux上のポータブルバイナリ実行ファイルに対する厳密に正しいアプローチは、Linux 標準ベースそしてその詳細な仕様LSBは、特定のライブラリバージョン（またはそれらのバージョンとの互換性）を指定することにより、互換性のあるディストリビューション間でバイナリ互換性を実現するように設計されています。LSB（または少なくとも過去のバージョン）は次のように公式化されました。国際標準化機構(ISO) 23360プログラムを LSB ライブラリ (およびプログラム自体に付属するライブラリ) のみにリンクするようにビルドすると、すべてのシステム間で移植可能になります。
LSB はパッケージの RPM 形式を指定するため、(厳密には) 1 つだけ作成する必要があります。パッケージ マネージャーとの統合を放棄する場合は、tarball でも十分です。
あなたの具体的な指摘のいくつかに関して：
彼らが正しいライブラリを持っていると仮定して、最善を祈るだけでいいのでしょうか?
かなり単純な LSB 互換プログラムは、多くのシステムでそのまま実行できる可能性が高いため、実行できます。
さらに、RHELやSUSEなど、いくつかのディストリビューションがLSB準拠の提供を試みています。他のディストリビューションでは、適切な依存関係を組み込む特定のパッケージを通じてLSB準拠を提供しています。たとえば、Debianにはパッケージlsbによって取り込まれlsb-core、さらに他のいくつかのパッケージが適切な依存関係を取り込みます。ソフトウェアを実行するには、ターゲット システムでこのようなパッケージをインストールする必要がある可能性があります。
LSBは以前ほど人気がなくなり、多くのシステムで正式な互換性は薄れていますが、実際にはかなり広い範囲で移植可能な状態で実行できます。準拠を目指すシステムでも、わかりにくい点がいくつか欠けていますが、一般的な用途では問題にならないことがよくあります（同じプログラムが、しないLSB 準拠を試みます。
このような場合、1、2 年後にライブラリの 1 つが変更され、アプリケーションが動作しなくなったらどうなるでしょうか?
アプリケーションが動作を停止すると、アプリケーションは動作を停止します。これはビジネス プロセスに関する質問です。
これらすべて (libstdc++、glibc など) をソフトウェアと一緒に配布する必要がありますか?
おそらくそうではありません。特に libc の場合、システム上で複数のバージョンを同時に使用すると、実行時の互換性の問題が発生する可能性があります。ただし、バンドルする方が実用的である可能性のある他の libc 実装もあります。
ほとんどのライブラリはバンドルできますが、ライブラリのベンダー化は一般的にメンテナンスとセキュリティの問題となるため、回避できる場合はそうしないことをお勧めします。ライブラリにバグやセキュリティ上の欠陥が見つかった場合、システム上の 1 か所で更新すると、ディストリビューションで対処されるため、すべてのコピーを追跡する (および交換パッケージを入手する) よりも簡単で信頼性が高くなります。
より現実的なステップとしては、クライアントにどこで実行したいかを尋ねてみるのがよいでしょう。あなたは熱心すぎるかもしれません。
答え2
実際には、いくつかの最も一般的な Linux ディストリビューション (およびバージョン) 用のバイナリ パッケージ (例: .debDebian および Ubuntu、.rpmFedora 用)。当然、Fedora と Ubuntu 用に異なるパッケージを作成する必要があります。また、Debian Jessie と Ubuntu 16.04 用に異なるパッケージを作成する必要があるかもしれません。ただし、時々Ubuntu 用のパッケージが (特定の) Debian にインストールされる可能性があり、その逆も同様です。
しかし、どこで実行できるか、つまりディストリビューションやカーネルのバージョンなどについて具体的な情報は提供されていません。
顧客と話し合う必要があります。
このような場合、1、2 年後にライブラリの 1 つが変更され、アプリケーションが動作しなくなったらどうなるでしょうか?
バイナリ パッケージの新しいバージョンを構築してリリースする必要があり、そのために労力 (および費用) がかかります。
一部のライブラリを静的にリンクしたい場合があります (技術的および法的に可能な場合) (LGPL ライセンスでは動的にリンクするか、クライアント マシンで静的に再リンクできるようにすることを推奨していることに注意してください)。たとえば、はlibstdc++よりもバージョンの影響を受けやすいため、静的にリンクすることも動的にlibcリンクすることもできます。実際には状況によって異なります。libstdc++libc
注意してくださいいくつかの特定のシステム ライブラリのバージョンは、実際には機能する場合と機能しない場合があります。一部のライブラリはシステム リソースを特定の方法で使用するため、詳細が非常に重要です。
PS. 顧客ともっと話し合って、フリーソフトウェア (オープンソース) の作成を提案した方がいいかもしれません。顧客によっては、それを好むかもしれません。