[root@PJDB-tpsgjk01 tpsg-ctp]# ldd main linux-vdso.so.1 (0x00007ffc2fff9000) libssl.so.3 => /lib64/libssl.so.3 (0x00007fc88cf70000) libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007fc88ca00000) libthosttraderapi_se.so => /lgh/tpsg-ctp/lib/libthosttraderapi_se.so (0x00007fc88be00000) libthostmduserapi_se.so => /lgh/tpsg-ctp/lib/libthostmduserapi_se.so (0x00007fc88b200000) librdkafka.so.1 => /lgh/tpsg-ctp/lib/librdkafka.so.1 (0x00007fc88ae00000) librdkafka++.so.1 => /lgh/tpsg-ctp/lib/librdkafka++.so.1 (0x00007fc88cf45000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc88aa00000) libm.so.6 => /lib64/libm.so.6 (0x00007fc88c925000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc88cf28000) libc.so.6 => /lib64/libc.so.6 (0x00007fc88a600000) /lib64/ld-linux-x86-64.so.2 (0x00007fc88d065000) libz.so.1 => /lib64/libz.so.1 (0x00007fc88c90b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc88cf23000) librt.so.1 => /lib64/librt.so.1 (0x00007fc88cf1c000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fc88c906000) libsasl2.so.3 => /lgh/tpsg-ctp/lib/libsasl2.so.3 (0x00007fc88c8e7000) libssl.so.1.1 => /lgh/tpsg-ctp/lib/libssl.so.1.1 (0x00007fc88bd6c000) libcrypto.so.1.1 => /lgh/tpsg-ctp/lib/libcrypto.so.1.1 (0x00007fc88a200000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc88c8d3000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fc88bd32000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fc88bcdc000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fc88b126000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fc88c8ba000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fc88c8b3000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fc88bccb000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fc88bcc4000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc88bc97000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fc88ad64000) 不要libssl.so.3 和 libcrypto.so.3 ！

<think>好的，我现在需要解决用户的问题，他们不希望使用libssl.so.3和libcrypto.so.3这两个库。用户提供的ldd输出显示，这两个库指向的是系统目录/lib64下的版本，但用户可能希望程序使用他们自己路径下的旧版本，比如/lgh/tpsg-ctp/lib/libssl.so.1.1和libcrypto.so.1.1。 首先，我应该考虑为什么程序会链接到系统路径的库而不是用户指定的。可能的原因是动态链接器在搜索路径时优先找到了系统库。要解决这个问题，通常的方法是修改动态链接库的搜索路径，让程序优先查找用户指定的目录。 接下来，我需要回忆动态链接库的加载顺序。Linux系统默认会按照LD_LIBRARY_PATH环境变量、/etc/ld.so.conf中的路径以及缓存中的路径来查找库。因此，用户可以通过设置LD_LIBRARY_PATH来优先加载指定目录的库。 但用户可能已经尝试过设置LD_LIBRARY_PATH，但未生效，或者系统库的优先级更高。这时候可能需要更彻底的方法，比如使用patchelf工具修改程序的RPATH，将用户库目录嵌入到可执行文件中，这样动态链接器会优先从这些路径查找库。 检查用户提供的ldd输出，发现libssl.so.3和libcrypto.so.3来自/lib64，而用户自己的库如libssl.so.1.1和libcrypto.so.1.1在/lgh/tpsg-ctp/lib下。这说明程序可能原本是链接到较新的OpenSSL 3.x版本，而用户希望使用1.1.x版本。这会导致兼容性问题，因为符号版本可能不同。 因此，用户需要确保他们的程序编译时链接的是正确的库版本，或者在运行时覆盖库的路径。如果程序已经编译完成，可能需要修改二进制文件的依赖关系，强制使用旧版库。 可能的步骤包括： 1. 设置LD_LIBRARY_PATH环境变量，将/lgh/tpsg-ctp/lib放在最前面。 2. 使用patchelf修改可执行文件的RPATH，添加用户库路径。 3. 检查是否安装了旧版本的OpenSSL开发包，并重新链接程序。 4. 确保所有依赖库的版本兼容，避免符号冲突。 需要注意的是，直接替换系统库可能会有风险，因此修改环境变量或RPATH是更安全的方法。此外，用户需要确认他们的程序确实支持旧版本的OpenSSL，否则可能会出现运行时错误。</think>根据您提供的 `ldd main` 输出和需求，以下是分步解决方案： **现象分析：** 1. 可执行文件 `main` 当前链接了系统库 `/lib64/libssl.so.3` 和 `/lib64/libcrypto.so.3` 2. 您希望强制使用 `/lgh/tpsg-ctp/lib/` 目录下的旧版本 `libssl.so.1.1` 和 `libcrypto.so.1.1` **解决方案：** 1. **环境变量法（临时生效）** ```bash # 设置动态链接库优先搜索路径 export LD_LIBRARY_PATH=/lgh/tpsg-ctp/lib:$LD_LIBRARY_PATH # 验证链接路径 ldd main | grep -E 'libssl|libcrypto' ``` 2. **修改 RPATH（永久生效）** ```bash # 安装必要工具 sudo yum install patchelf # 修改可执行文件的库搜索路径 patchelf --set-rpath '/lgh/tpsg-ctp/lib' main # 验证修改结果 readelf -d main | grep RPATH ``` 3. **符号链接覆盖法（需root权限）** ```bash # 备份原有库文件 sudo mv /lib64/libssl.so.3{,.bak} sudo mv /lib64/libcrypto.so.3{,.bak} # 创建符号链接指向目标版本 sudo ln -s /lgh/tpsg-ctp/lib/libssl.so.1.1 /lib64/libssl.so.3 sudo ln -s /lgh/tpsg-ctp/lib/libcrypto.so.1.1 /lib64/libcrypto.so.3 ``` **注意事项：** 1. 版本兼容性问题：OpenSSL 1.1.x 与 3.x 存在 API 不兼容，需确认程序支持旧版本 2. 推荐顺序：优先使用方案1（环境变量）→ 其次方案2（RPATH）→ 最后方案3（需要评估系统影响） 3. 验证方法：执行 `ldd main` 后应显示： ``` libssl.so.3 => /lgh/tpsg-ctp/lib/libssl.so.1.1 libcrypto.so.3 => /lgh/tpsg-ctp/lib/libcrypto.so.1.1 ``` **补充建议：** 如果程序自行编译构建，建议在编译时指定库路径： ```bash ./configure --with-openssl=/lgh/tpsg-ctp/lib # 或 cmake -DOPENSSL_ROOT_DIR=/lgh/tpsg-ctp/lib ```