所以我在 debian 9 x64 上构建了curl（可能是错误的），在curl -V命令之后我可以看到它使用新版本：
OpenSSL/1.1.0f
之后，我将完全相同的库复制到另一个 debian 9 实例中，运行curl -VI 后发现它使用旧版本：
OpenSSL/1.0.2l
-这是什么原因？
-这是否意味着我以某种方式错误地构建了curl，并且实际的openssl版本不是它显示的版本？
- openssl 不是静态构建的，因此保留在curl 二进制文件中吗？
答案1
首先...
你不需要做任何这些
您链接到的错误已在 Curl 中修复版本7.51.0。
- openssl：使用 1.0.1 或 1.0.2 修复每线程内存泄漏
您指定了 Debian Stretch，它目前使用7.52.1。安装旧版本的 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 的版本）。