RHEL-7编译二进制依赖libcrypt.so.1无法在RHEL-10运行的替代方案咨询

• 软链接的临时可行性：
  RHEL10中的libcrypt.so.2来自独立的libxcrypt库，该库设计时提供了对旧版libcrypt.so.1（原属于glibc）的ABI兼容层，因此仅依赖标准crypt接口（如crypt()、crypt_r()）的程序大概率能临时运行，但这属于非官方的 workaround，不建议长期使用。

• 潜在的运行时风险：

  1. 接口/符号不兼容：若程序依赖了旧版libcrypt.so.1中的私有符号、已废弃加密算法或非标准扩展接口，软链接后可能出现崩溃、加密结果错误或未定义行为。
  2. 安全合规隐患：客户因安全扫描风险拒绝了复制库的方案，直接修改系统级库的软链接会破坏系统默认配置，大概率触发安全工具告警，且违反RHEL官方配置规范。
  3. 更新兼容性问题：后续RHEL10更新libxcrypt库时，可能调整兼容逻辑或移除旧兼容层，导致程序突然失效，且无法获得RedHat官方技术支持。

• 更稳妥的替代方案（除重新编译）：

  1. 容器化部署：将程序打包在基于RHEL7的容器镜像中，在RHEL10上通过Podman或Docker运行，完全隔离依赖环境，既满足兼容性又符合安全合规要求。
  2. 静态编译：若程序源码允许，在RHEL7上进行静态编译（将所有依赖库打包进二进制文件），生成不依赖系统库的可执行文件，不过需注意静态编译的安全补丁更新成本。

内容的提问来源于stack exchange，提问作者Amit