所以我在debian 9 x64上建構了curl（可能不正確），在curl -V命令之後我可以看到它使用了新版本：

OpenSSL/1.1.0f

之後，我將相同的庫複製到另一個 debian 9 實例中，並在執行 curl -VI 後看到它使用的是舊版本：

OpenSSL/1.0.2l

• 這是什麼原因？

• 這是否意味著我以某種方式錯誤地建構了 curl 並且實際的 openssl 版本不是它顯示的版本？

-openssl 不是靜態建構的，因此保留在 curl 二進製文件中嗎？

首先…

你不需要做任何這些

您連結到的錯誤已在 Curl版本 7.51.0中修復。

• openssl：使用 1.0.1 或 1.0.2 修復每個執行緒的記憶體洩漏

您指定了目前使用 7.52.1的 Debian Stretch 。安裝舊版本的 OpenSSL 並不重要——您仍然擁有更新的 Curl。

因此，只要該系統一直保持最新（通過apt），它就已經有了修復。

動態或靜態

現在，到你原來的問題：

openssl 不是靜態建構的，因此保留在 curl 二進製文件中嗎？

不可以。除非您在執行時設置了一些特定變數，否則./configure生成的執行檔是動態連結的，並且需要單獨的libcurl.so. 其中之一將同時建成。

除非您將該庫文件複製到第二台伺服器並將其放置在載入程序可以找到它的路徑中，否則您將使用已安裝的文件（在 下/usr/lib/x86_64-linux-gnu/）。如果您readelf -d在該文件上執行，您將看到它連結的 OpenSSL 版本。

0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.0.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）。

引用自：https://unix.stackexchange.com/questions/470256