web-dev-qa-db-ja.com

顧客のLinuxでlibsslを見つける

バージョン1.0.*でlibsslをロードする必要があるライブラリを使用しています。 libssl.so.1.1では機能しません。どのLinuxシステムでも動作する必要があります。

私たちはさまざまなバージョンをロードしようとしますが、これは通常は機能しますが、1人の顧客のシステムでは、次のものだけがあります。

/usr/lib64/libssl.so.1.1.0g
/usr/lib64/libssl.so.10
/usr/lib64/libssl.so.1.0.2m
/usr/lib64/libssl.so.1.1

libssl.so.1.0とlibssl.so.1.0.2を読み込もうとしていますが、末尾の "m"が原因でlibssl.so.1.0.2mが見つかりません。

もしあれば、libsslの命名方式は何ですか？

本当に私たち自身のバージョンを提供する必要がありますか、それとももっと良い方法がありますか？

libssl.so.1.0.2zからlibssl.so.1.0.2aまでループする必要がありますか？ライブラリパスを手動でスキャンする必要がありますか？

linuxopenssllibrariesshared-library
2
maaartinus

libsslを開く方法がわかりません-dlopen()を想定していますか？

ライブラリのディレクトリパスのハードコーディングされたリストを検索すると、かなり壊れやすいように思われます。動的リンカーに処理を任せた方がよいでしょう。おそらくldconfig -pの出力を解析することは試す価値がありますか？ Debianシステムでは、次のようになります。

$ ldconfig -p|grep ssl
libssl.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.1
libssl.so.1.0.2 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2

RHEL 7.4システムの場合：

$ ldconfig -p|grep ssl
libssl3.so (libc6,x86-64) => /lib64/libssl3.so
libssl.so.10 (libc6,x86-64) => /lib64/libssl.so.10

Debianシステムではライブラリは/usr/lib/x86_64-linux-gnuにありますが、RHELシステムでは/lib64にあります（さまざまなライブラリ名にも注意してください）。 ldconfigの出力のようなものを使用しない限り、「任意のLinuxシステムで作業する」場合は、ディストリビューション固有のすべてのパスを自分で検索する必要があります。確かに、ディレクトリパスは/etc/ld.so.confにリストされていますが、ldconfigを使用する方がおそらく簡単です。

3
mjturner