我通过使用 openssl 版本 OpenSSL 1.1.1d 动态链接 SLES15 计算机上的 openssl 库并使用 openssl 版本 OpenSSL 1.1.0i-fips 在 SLES15SP1 上运行应用程序来构建我的 C++ 应用程序，但应用程序无法运行并退出，并出现以下错误“/usr/lib64/libssl.so.1.1：找不到版本‘OPENSSL_1_1_1’”
我的测试机器是SLES15SP1，它有openssl版本OpenSSL 1.1.0i-fips
V2A-GQL-S15SP1:/tmp/remoteinstall/WMISSH/3 # openssl 版本 OpenSSL 1.1.0i-fips 2018 年 8 月 14 日
我的 SLES15 构建机器具有更高的 openssl 版本 OpenSSL 1.1.1d 163e172dceca:/ # openssl 版本 OpenSSL 1.1.1d 2019 年 9 月 10 日
是否有这样的要求：测试机需要具有与构建机相同或更高版本的 openssl？
请指导如何使用动态开放 ssl 链接构建 C++ 应用程序，以便应用程序可以选择系统中存在的任何版本的 openssl。
请指导如何使用动态开放 ssl 链接构建 C++ 应用程序，以便应用程序可以选择系统中存在的任何版本的 openssl。
这几乎是不可能的。 OpenSSL 对其库进行了严格版本控制，因为版本之间的 API 存在不兼容的差异。
您必须在开发系统上安装与所需版本兼容的 OpenSSL 1.1.0 版本，然后修改您的应用程序以使用该版本。一旦进行了必要的更改，您就必须测试您的应用程序。然后将该版本交付给过时的系统。
换句话说，您必须分叉您的应用程序并维护两个分支。您有资源做到这一点吗？对于已经 EOL 的过时系统？
因为这些系统已经过时并且已经停产。他们将不会获得安全更新。根据 SUSE Linux Enterprise Server 中 OpenSSL 版本概述，唯一采用 OpenSSL 1.1.0 的 SLES 15 版本已于两年多前停产。大约一个月后唯一不会停产的 SLES 15 版本是 SLES 15 sp5 重要的是，OpenSSL 1.1.1 本身已停产：“OpenSSL 1.1.1 于 2018 年 9 月 11 日发布，因此将于 2023 年 9 月 11 日被视为 EOL。此后它将不再接收公开可用的安全修复程序那个日期。”
SUSE 可能已提供支持，为其 OpenSSL 1.1.1 软件包提供与安全相关的修复，但时间可能有限。 SUSE 可能会将 SLES 15 sp6 或 sp7 中的 OpenSSL 版本更改为 OpenSSL 3.0，因为他们在不久的将来没有资源为 OpenSSL 1.1.1 提供关键的安全修复程序。例如，RHEL 8 显示在 2025 年中期之后不再提供扩展支持 - 仅距 18 个月左右。 OpenSSL 1.1.1 的 EOL
是做出该决定的重要推动因素