linuxの下でライブラリ依存関係のあるcプログラムを配布するためのオプション

Question

いくつかのリモートホスト上で動作させることを意図したlibmysqlclient.soなどのダイナミックライブラリを必要とするCプログラムを開発しました。私は以下の配布オプションがあるようです：

1. プログラムを静的にコンパイルします。
2. リモートホストに必要な依存関係をインストールします。
3. 依存関係をプログラムに配布します。

とにかく実行時にglibc-versionが必要になるため、最初のオプションが問題になります（今はglibcとlibnssを使用しているため）。

2番目のオプションについてはわかりません：インストールされたライブラリバージョンでは、（libxyz.so.VERSIONの横の）プログラムを実行するのに十分であるかどうかをチェックするメカニズムはありますか？私は起動時に何とかABI互換性をチェックできますか？

最後のオプションについて：すべての共有ライブラリをバイナリで配布するか、おそらくインストールされていないもの（libmysqlclient、libmなど）を配布しますか？

これとは別に、別のコンパイラをバイナリに使用し、依存関係がビルドされたもの（バイナリclang、ライブラリgccなど）を使用するとABI互換性の問題が発生する可能性がありますか？

Answer 1

バージョンチェックは配布固有です。通常、ターゲット配布パッケージツールを使用して.debまたは.rpmファイルにアプリケーションをパッケージし、ユーザーに配布します。これは、サポートされているディストリビューションごとにアプリケーションをビルドする必要があることを意味しますが、異なるディストリビューションではわずかに異なるバージョンのlibmysqlclientがあるため、実際にはその方法はありません。これらのディストリビューションビルドツールはいくつかの依存バージョン情報を自動的に生成し、それ以外の場合は手作業によるヘルプが必要になります。

出発点として、MySQL/MariaDBクライアントライブラリに依存するものを配布パッケージで見て、それをコピーすることをお勧めします。 Debianのinspircdが良い例です。

サポートしたい最も古いディストリビューションバージョンをビルドすることで、作成してテストする必要があるビルドの量をいくらか減らすことができます。しかし、いくつかの警告が適用されます。分布はそれらが提供する下位互換性の程度が異なる。

libmysqlclientなどの一般的なライブラリも基本オペレーティングシステムで提供されており、LD_LIBRARY_PATHを使用して独自のバージョンをインジェクトすると、意図せず他のプログラムにも拡張される可能性があるため、自分のプログラムから起動したもの）。後者のリスクは、DT_RUNPATH（-rpathリンカオプションを使用）を使用しても、やや減少しますが、依然として存在します。

異なるオプションは、アプリケーション固有のサポートライブラリを静的にリンクし、基本オペレーティングシステムライブラリを動的にリンクすることです。しかし、これは、libmysqlclientの場合にはあまり適していないようですが、その機能セットが（TLSライブラリと利用可能な設定オプションに関する）ディストリビューションと同じであることが予想されるため、 、静的リンクを使用すると、これを達成することは困難です。