Linux共有オブジェクトライブラリのリンク

Question

私は使用したいライブラリを持っています。私はそれのためのソースコードを持っていないが、それは私が使用したい機能が含まれています。これは通常のx86-64共有オブジェクトで、その中にはいくつかのJNIコードがあり、特別なものはありません。私の問題は、ライブラリがlibm.soを参照するようになったことです。今起こっていることはかなり奇妙で、私はそれを期待していませんでした。実行しようとすると、libm.soには無効なELFヘッダーがあることがわかります。libm.soは実際のライブラリファイルのlibm.so.6への参照ファイルなので意味があります。

私の質問は、これを修正する方法です。私は、オペレーティングシステムがそれを正しく処理しないことに本当に驚いています。それは、少なくともいくらかバージョンに依存しないので、すべてのプログラムがlibm.soを参照し、libm.so.6ではないからです。

EDIT：私はstraceとlibm.soマイライブラリは、Linuxの多くの一般的な標準ライブラリに参照している...氷山の一角であるように思わをしました。そして私はJREでそれを実行しているので、それはJREのディレクトリ内を検索するだけであり、それはまったく間違っています。ライブラリはAndroid Appから取得されているので、元のメイクファイルにはおそらくどちらの意味もないライブラリのパスがあったでしょう...この問題を解決するためにはもう少し分析しなければなりません。

Answer 1

インポートはlibm.so.6である必要があります。 libm.soのインポートは、コンパイル中にのみ行う必要があります。結果のELFは前者をインポートする必要があります。

これはABIバージョンと呼ばれます。特定のバージョンのライブラリにリンクしている場合、リンクしたバージョンと互換性のある実際のインポートのみが取得されることを確認するためのものです。その番号がいつ変更されるかについては、いくらか複雑な規則があります（詳細はsonameを参照してください）。

悲しいことに、実際の質問はしていません。これは、インポートが失敗した理由を説明していません。 ELFヘッダーが間違っていると、間違った場所でそれを探しています（もっと正確には、ld.soを探して探しています）。

straceでコードを実行して、実際に開いているファイルを確認します。その後、fileを実行すると、プラットフォームが一致していることがわかります（実行可能な64ビットの実行ファイルが32ビットライブラリを開こうとしているか、またはその逆）。