Linuxダイナミックリンカーからの「バージョン情報がありません」というエラーはどういう意味ですか？

私たちの製品では、「libpam」のようなシステムライブラリに動的にリンクするいくつかのLinuxバイナリを出荷しています。一部のお客様のシステムでは、プログラムの実行時にstderrで次のエラーが発生します。

./authpam: /lib/libpam.so.0: no version information available (required by authpam)

アプリケーションは正常に実行され、ダイナミックライブラリからコードを実行します。したがって、これは致命的なエラーではなく、実際には単なる警告です。

これは、システムにインストールされたライブラリに実行可能ファイルが期待するものがない場合のダイナミックリンカによるエラーだと思います。ダイナミックリンクプロセスの内部についてはよくわかりません...トピックをグーグルで検索してもあまり役に立ちません。:(

このエラーの原因を知っている人はいますか？...どうすれば原因を診断できますか？...そして、この問題を回避するために実行可能ファイルを変更するにはどうすればよいですか？

更新：お客様が最新バージョンのDebian「テスト」にアップグレードしたところ、同じエラーが発生しました。したがって、それは古いlibpamライブラリではありません。リンカーが何について不平を言っているのか理解したいと思いますか？根本的な原因などを調査するにはどうすればよいですか？

「使用可能なバージョン情報がありません」は、ライブラリのバージョン番号が共有オブジェクトで小さいことを意味します。たとえば、バイナリをビルドするマシンでmajor.minor.patch番号が7.15.5で、インストールマシンでmajor.minor.patch番号が7.12.1の場合、ldは警告を出力します。

これは、ターゲットOSに付属の共有オブジェクトバージョンと一致するライブラリ（ヘッダーと共有オブジェクト）を使用してコンパイルすることで修正できます。たとえば、RedHat 3.4.6-9にインストールする場合は、Debian4.1.1-21でコンパイルする必要はありません。これが、ほとんどのディストリビューションが特定のLinuxディストリビューション番号で出荷される理由の1つです。

それ以外の場合は、静的にリンクできます。ただし、PAMのようなものではこれを実行したくないため、クライアントの実稼働環境に一致する開発環境を実際にインストールする必要があります（または、少なくともインストールして、正しいライブラリバージョンに対してリンクします）。

.soファイルの名前を変更する（バージョン番号をパディングする）ためのアドバイスは、共有オブジェクトライブラリがバージョン管理されたシンボルを使用していなかった時代に由来しています。したがって、.so.nnn命名スキームで遊ぶことが役立つとは思わないでください（システムがゴミ箱に捨てられた場合に役立つ可能性があります）。

最後のオプションは、カスタムリンクスクリプト（http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts）を使用して、マイナーバージョン番号が異なるライブラリでコンパイルすること です。 html

これを行うには、カスタムスクリプトを作成する必要があります。また、カスタムスクリプトを使用して、クライアントの共有オブジェクトに対してldを実行するカスタムインストーラーが必要です。これには、クライアントの本番システムにgccまたはldがインストールされている必要があります。

glibcダイナミックリンカーからのこのメッセージが実際に意味するのは、言及されたライブラリ（/lib/libpam.so.0あなたの場合）にはVERDEFELFセクションがないのに対し、バイナリ（authpamあなたの場合）にはVERNEEDこのライブラリのセクションにいくつかのバージョン定義があるということです（おそらくlibpam.so.0）。とセクション（またはその欠如）をreadelf見るだけで簡単に見ることができます。.gnu.version_d.gnu.version_r

したがって、これはシンボルバージョンの不一致ではありません。バイナリが特定のバージョンを取得VERNEEDする必要があり、ライブラリが実際VERDEFにそれを提供しなかった場合、それはハードリンカーエラーになり、バイナリはまったく実行されません（このように）これまたはあれと比較して）。バイナリがいくつかのバージョンを必要としているということですが、ライブラリはそのバージョンに関する情報を提供していません。

実際にはどういう意味ですか？通常、この例に見られるものとまったく同じです。何もありません。バージョン管理を無視して機能します。物事が壊れることはありますか？もちろん、そうです。他の答えは正しいので、実行時に、バイナリがビルド時にリンクされたライブラリと同じライブラリを使用する必要があります。

詳細については、UlrichDreppersの「 ELFSymbolVersioning 」を参照してください。

Fwiw、zenoss監視システムがインストールされているシステムでcheck_nrpeを実行すると、この問題が発生しました。混乱を増すために、rootユーザーとしては正常に機能しましたが、zenossユーザーとしては機能しませんでした。

zenossユーザーがLD_LIBRARY_PATHを持っていたため、これらの警告を発行するzenossライブラリが使用されていることがわかりました。すなわち：

root@monitoring:$ echo $LD_LIBRARY_PATH

su - zenoss
zenoss@monitoring:/root$ echo $LD_LIBRARY_PATH
/usr/local/zenoss/python/lib:/usr/local/zenoss/mysql/lib:/usr/local/zenoss/zenoss/lib:/usr/local/zenoss/common/lib::
zenoss@monitoring:/root$ /usr/lib/nagios/plugins/check_nrpe -H 192.168.61.61 -p 6969 -c check_mq
/usr/lib/nagios/plugins/check_nrpe: /usr/local/zenoss/common/lib/libcrypto.so.0.9.8: no version information available (required by /usr/lib/libssl.so.0.9.8)
(...)
zenoss@monitoring:/root$ LD_LIBRARY_PATH= /usr/lib/nagios/plugins/check_nrpe -H 192.168.61.61 -p 6969 -c check_mq
(...)

とにかく、私が言おうとしているのは、LD_LIBRARY_PATH、LD_PRELOADなどの変数も確認することです。

アプリをどのようにコンパイルしていますか？どのコンパイラフラグですか？

私の経験では、Linuxシステムの広大な領域をターゲットにする場合は、サポートする最も古いバージョンでパッケージをビルドします。下位互換性のあるシステムが増える傾向があるため、アプリは引き続き機能します。実際、これがライブラリのバージョン管理の理由です。下位互換性を確保します。

これはもう見たことがありますか？原因の1つ、おそらくその顧客の非常に古いlibpamが原因のようです。

または、バージョンのリンクが欠落している可能性があります：http：//www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html