web-dev-qa-db-ja.com

Linuxダイナミックリンカーからの「バージョン情報なし」エラーはどういう意味ですか？

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

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

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

これは、システムにインストールされたライブラリに実行可能ファイルに必要なものが欠けている場合に、ダイナミックリンカーから発生したエラーであると考えられます。動的リンクプロセスの内部についてはあまり知りませんが、トピックをグーグルで検索してもあまり役に立ちません。 :(

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

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

linuxlinker
76
Matt Doran

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

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

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

.soファイルの名前を変更する（バージョン番号でパディングする）アドバイスは、共有オブジェクトライブラリがバージョン管理されたシンボルを使用しなかったときに生じます。したがって、.so.n.n.n命名スキームを使用することが役立つとは思わないでください（多くの場合、システムが破壊されている場合に役立ちます）。

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

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

58
Chris

Glibc動的リンカからのこのメッセージが実際に意味するのは、ライブラリが言及したことです（/lib/libpam.so.0にはVERDEF ELFセクションがありませんが、バイナリ（authpam）にはこのライブラリのVERNEEDセクションにいくつかのバージョン定義があります（おそらく） 、libpam.so.0）。 readelfで簡単に確認できます。.gnu.version_dおよび.gnu.version_rセクション（またはその欠如）。

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

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

詳細については、Ulrich Dreppers "ELF Symbol Versioning" を参照してください。

15
Roman Khimov

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

Zenossユーザーには、これらの警告を発行するzenossライブラリを使用させるLD_LIBRARY_PATHがあることがわかりました。すなわち：

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などの変数もチェックしてください。

4
Dieter_be

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

私の経験では、Linuxシステムの広大な領域を対象とする場合、サポートを希望する最も古いバージョンでパッケージをビルドします。多くのシステムは後方互換性がある傾向があるため、アプリは引き続き動作します。実際、これがライブラリのバージョン管理の全体的な理由です-後方互換性を保証します。

3
Ted Percival

this をすでに見ましたか？原因は、おそらくその顧客のいずれかの側の非常に古いlibpamのようです。

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

1
Vinko Vrsalovic