HPUX 11.31 Subversion客户端打安全补丁后无法连接远程仓库求助

故障根因定位 #

• 报错本质是HPUX动态链接器加载SVN依赖的/usr/local/lib/hpux32/libneon.so时，找不到该库依赖的导出符号SSL_load_error_strings
• 触发原因是IT部门部署的安全补丁升级了系统32位OpenSSL库，移除了旧版本长期保留的兼容导出符号，且当前环境无法回退补丁，需要调整依赖匹配关系解决问题
• 需注意当前使用的SVN 1.7.8为32位构建，配套的libneon也是32位版本，排查、替换依赖时不要混入64位库文件

可落地解决步骤 #

第一步：依赖匹配校验 #

执行以下命令确认依赖关系匹配度：

• 查看libneon的动态依赖指向：ldd /usr/local/lib/hpux32/libneon.so，确认输出中libssl、libcrypto的加载路径为系统补丁更新后的32位OpenSSL库（通常路径为/usr/lib/hpux32/libssl.so、/usr/lib/hpux32/libcrypto.so）
• 校验符号缺失情况：nm /usr/lib/hpux32/libssl.so | grep SSL_load_error_strings，若无匹配输出，即可确认是OpenSSL版本升级导致的符号不匹配

优先方案：重编译适配当前OpenSSL版本的libneon #

该方案完全兼容现有已部署的安全补丁，不会破坏系统安全配置：

• 从本地软件备份目录取出与当前部署版本匹配的neon库源码（版本需和现有libneon.so对应，避免引入SVN兼容问题）
• 配置32位编译参数，显式指定适配当前系统OpenSSL路径：./configure --host=hppa2.0w-hp-hpux11.31 --prefix=/usr/local --with-ssl=/usr/lib/hpux32 --enable-shared
• 编译完成后先备份原有旧库：mv /usr/local/lib/hpux32/libneon.so /usr/local/lib/hpux32/libneon.so.bak，再将新编译的32位libneon.so放入对应hpux32库目录
• 执行svn status -u验证远程仓库连接是否恢复
• 注意编译时需确保链接到补丁更新后的OpenSSL库，不要关联到其他路径存储的旧版本OpenSSL文件，否则会重复触发符号缺失报错

应急方案：构建符号兼容层 #

该方案无需源码编译整套neon库，适合业务紧急需要恢复访问的场景：

• 排查当前OpenSSL库中替代SSL_load_error_strings的对应函数实现
• 编写薄兼容C层代码，将缺失的SSL_load_error_strings调用转发到现有OpenSSL的对应初始化逻辑，编译为32位共享库放入/usr/local/lib/hpux32目录
• 调整动态库加载优先级，让链接器优先从兼容库中找到缺失符号

长期方案：升级适配当前补丁的SVN构建包 #

• 从企业内部软件仓库获取适配当前HPUX OpenSSL补丁版本的SVN安装包（可兼容现有远程仓库版本即可，无需强制升级SVN大版本）
• 安装前备份原有SVN二进制、依赖库路径，安装过程中不要覆盖系统已部署的OpenSSL补丁文件，仅替换SVN自身二进制和配套libneon依赖
• 安装完成后执行svn --version确认客户端版本正常，再验证远程仓库连接

操作注意事项 #

• 所有操作不得修改、覆盖IT部门已部署的系统OpenSSL安全补丁文件，避免违反安全合规要求
• 替换任何系统、软件依赖库前必须对原有文件做备份，出现操作异常时可快速回退
• 严禁将64位架构的libneon、OpenSSL库文件放入32位库路径，否则会触发HPUX平台的架构不兼容报错

内容的提问来源于stack exchange，提问作者Jeffrey D Winnett