☰

このうち何もする必要はありません

tag-icon • tag-icon debian curl openssl libraries
このうち何もする必要はありません

だから私はdebian 9 x64（おそらく間違っているかもしれません）でカールを作成し、curl -Vコマンドの後に新しいバージョンを使用するのを見ることができます。

OpenSSL/1.1.0f

その後、まったく同じライブラリを別のdebian 9インスタンスにコピーし、Cal -VIを実行して以前のバージョンを使用していることを確認しました。

OpenSSL/1.0.2l

-理由は何ですか？

- これは私がカールを間違って構築し、実際のopensslバージョンが表示されるバージョンではないことを意味しますか？

- opensslは静的に構築されていないので、カールバイナリに残りますか？

答え1

最初...

このうち何もする必要はありません

あなたがリンクしたバグはCurlで修正されました。バージョン 7.51.0。

  • openssl：1.0.1または1.0.2を使用してスレッド固有のメモリリークを修正する

Debian Stretchを指定しました。現在7.52.1を使用しています。。以前のバージョンの OpenSSL がインストールされているかどうかは問題ではありません。まだ最新のCurlがインストールされているからです。

したがって、システムが最新のままである限り（通過）、すでにapt修正されています。

動的または静的

さて、元の質問に戻ります。

opensslは静的に構築されていないため、カールバイナリに残りますか？

習慣。実行時に特定の変数を設定しない限り./configure、結果の実行可能ファイルは動的にリンクされ、libcurl.soそのうちの1つを同時に構築する必要があります。

ライブラリファイルを2番目のサーバーにコピーしない限りローダーが見つけることができるパスに配置します。を選択すると、インストールされているもの（下/usr/lib/x86_64-linux-gnu/）を使用します。あなたreadelf -dが飛び込むならそれファイルを見ると、どのバージョンのOpenSSLが接続されているかを確認できます。

 0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.0.2]

もしあなたなら持つ2番目のサーバーで最新バージョンを試してみると、次libcurl.so.4のエラーが表示されます。

error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

要約すると、あなたのCurlのコピーはインストールされたOpenSSLバージョンを使用し、正しく報告しています。メモリリークの影響を受ける唯一の方法は、修正前にCurlバージョン（つまり7.51.0より前のバージョン）を手動でビルドした場合です。

関連情報