4

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 プログラムを作成するのは本当に複雑ですか? 私がやりたいことをするための何らかの基準はありますか?それとも、ハックな方法でそれを行う運命にありますか?

コメント/解決策をありがとう!

4

1 に答える 1

2

Linux の主な設計上の欠陥は、プログラムをソース コード形式ではなくバイナリ形式で配布する場合の共有オブジェクト地獄だと思います。

システムの作成者に関する限り、これは設計上の欠陥ではありません。これは利点です。プログラムをソース形式で配布することが奨励されます。ああ、あなたはあなたのソフトウェアを売りたかったのですか?申し訳ありませんが、これは Linux が最適化されているユース ケースではありません。

ライブラリの命名規則: 多くの場合、共有オブジェクトは単純に「libXcursor.so」と呼ばれるのではなく、「libXcursor.so.1」のようなある種のバージョン拡張や、「libXcursor.so.0.2000」のような非常に面白いものさえあります。

はい、これは外部ライブラリのバージョン管理と呼ばれます。ここでそれについて読んでください。その説明から明らかなように、通常libXcursor.so.1は実行時の参照として提供されるシステムでヘッダーを使用してバイナリをコンパイルした場合、互換性のある唯一libXcursor.so.1の共有ライブラリは であり、それを試みるとdlopen libXcursor.so.0.2000予期しないクラッシュが発生します。

提供しているが提供してlibXcursor.soいないシステムlibXcursor.so.1は、インストールが壊れているか、バイナリと互換性がありません。

ライブラリ検索パス: 結局、*.so ファイルはどこで探せばよいのでしょうか?

フル パスを使用してこれらのライブラリを dlopen しようとしないでください。を呼び出すだけで、ランタイム ローダーがシステムに適しdlopen("libXcursor.so.1", RTLD_GLOBAL);た場所でライブラリを検索します。

于 2013-04-14T21:29:43.720 に答える