Linux の主な設計上の欠陥は、プログラムをソース コード形式ではなくバイナリ形式で配布する場合の共有オブジェクト地獄だと思います。
ここに私の問題があります: Linux プログラムを ELF バイナリ形式で公開し、できるだけ多くのディストリビューションで実行して、必須の依存関係を可能な限り低くしたい: どのような状況でも必要なライブラリは、libpthread、libX11、librt だけです。そしてlibm（そしてもちろんglibc）。gcc を使用してプログラムをビルドするときに、これらのライブラリに対して動的にリンクしています。
ただし、必要に応じて、私のプログラムは ALSA (サウンド インターフェイス)、Xcursor、Xfixes、Xxf86vm 拡張機能、および GTK もサポートする必要があります。ただし、これらはユーザーのシステムで利用できる場合にのみ使用する必要があります。そうでない場合、プログラムは引き続き実行されますが、機能は制限されます。たとえば、GTK が存在しない場合、プログラムは端末モードにフォールバックします。私のプログラムは ALSA、Xcursor、Xfixes などがなくても実行できるはずです。これらのライブラリに対して動的にリンクすることはできません。ライブラリの 1 つが存在しない場合、プログラムはまったく起動しないからです。
そのため、ライブラリが存在するかどうかを手動で確認し、dlopen() を使用してそれらを 1 つずつ開き、dlsym() を使用して必要な関数シンボルをインポートする必要があります。ただし、これはあらゆる種類の問題につながります。
1) ライブラリの命名規則: 多くの場合、共有オブジェクトは単純に「libXcursor.so」と呼ばれるのではなく、「libXcursor.so.1」のようなある種のバージョン拡張や、「libXcursor.so.0.2000」のような非常に面白いものさえあります。これらの拡張子は、システムごとに異なるようです。では、dlopen() を呼び出すときにどちらを選択すればよいでしょうか? ここでハードコーディングされた名前を使用することは、システムによって名前が異なるため、非常に悪い考えのように思えます。したがって、私の頭に浮かぶ唯一の回避策は、ライブラリ パス全体をスキャンし、「libXcursor.so」プレフィックスで始まるファイル名を探してから、カスタム バージョン マッチングを行うことです。しかし、それらが本当に互換性があることをどうやって知ることができますか?
2) ライブラリ検索パス:結局、*.so ファイルはどこで探せばよいのでしょうか? これもシステムごとに異なります。/usr/lib や /lib などのデフォルト パスがいくつかありますが、*.so ファイルは他の多くのパスにも存在する可能性があります。したがって、/etc/ld.so.conf を開いてこれを解析し、すべてのライブラリ検索パスを見つける必要があります。/etc/ld.so.conf ファイルはある種のincludeディレクティブも使用できるため、これは簡単なことではありません。これは、さらに多くの .conf ファイルを解析し、循環的なincludeディレクティブによって引き起こされる可能性のある無限ループに対していくつかのチェックを行う必要があることを意味します。 *.so の検索パスを簡単に見つける方法はないのでしょうか?
だから、私の実際の質問はこれです: 私がやりたいことを達成するための、より便利でハックの少ない方法はありませんか? ALSA、GTK、libXcursor などのオプションの依存関係を持つ Linux プログラムを作成するのは本当に複雑ですか? 私がやりたいことをするための何らかの基準はありますか？それとも、ハックな方法でそれを行う運命にありますか?
コメント/解決策をありがとう！