MIPS64 Cavium平台交叉编译OpenSSH动态链接启动段错误求助

嘿，你在Cavium MIPS64平台交叉编译OpenSSH 8.4p1时遇到的这个SIGSEGV（地址无效的段错误），大概率和N32 ABI的一致性或者动态库加载冲突有关——毕竟MIPS的几种ABI（o32/n32/64）兼容性极差，稍微有不匹配就会触发崩溃。结合你给出的LD_DEBUG日志，我整理了几个具体的排查和修复步骤：

1. 先确认所有库的ABI完全一致 #

你虽然编译时都加了-mabi=n32，但最好实际验证每个生成的文件是否真的符合N32 ABI要求：

• 用交叉工具链的readelf检查每个库和二进制文件：

  mips64-octeon-linux-gnu-readelf -h /mnt/cf/libcrypto.so.1.1 /mnt/cf/libz.so.1.2.11 /mnt/cf/sshd_dyn
  

  重点看输出里的ABI字段是不是MIPS N32，Class是不是ELF32（N32是32位地址空间、64位寄存器的混合ABI，因此对应ELF32格式）。如果某个库是ELF64或者o32 ABI，那必然会导致地址访问错误，得重新编译这个库。

2. 强制优先加载你自己编译的依赖库 #

从LD_DEBUG=symbols日志能看到，系统先尝试加载/lib32/octeon2/libpthread.so.0，然后才是你放在/mnt/cf的libc。目标机上的系统库很可能是o32或者64位的，和你的N32库不兼容：

• 运行时用LD_LIBRARY_PATH强制优先加载你编译的库目录：

  LD_LIBRARY_PATH=/mnt/cf:$LD_LIBRARY_PATH ./sshd_dyn
  

• 如果你的交叉工具链自带N32版本的系统库（比如sysroot目录下的），编译OpenSSH时最好加上--with-sysroot=<你的工具链sysroot路径>，让它链接工具链里的N32系统库，而不是目标机上的旧库。

3. 给OpenSSL用更精准的MIPS配置选项 #

你用了linux-generic64配置OpenSSL，但Cavium Octeon是MIPS64r2架构，通用配置可能生成的代码存在兼容性问题：

• 换成MIPS专用的配置，加上架构优化：

  CC=mips64-octeon-linux-gnu-gcc CFLAGS="-mabi=n32 -march=octeon2" ./Configure no-hw linux-mips64 shared --prefix=/mnt/cf
  

  加上-march=octeon2能让OpenSSL生成适配Cavium芯片的代码，避免通用MIPS64代码在Octeon上的异常。

4. 用core dump定位具体崩溃点 #

既然已经生成了core dump，直接用交叉gdb分析是最直接的方式：

mips64-octeon-linux-gnu-gdb ./sshd_dyn core

输入bt查看调用栈，如果崩溃发生在动态链接器阶段（比如dlopen或者符号查找），那基本可以确定是ABI不匹配；如果是调用EVP_aes_256_ctr时崩溃，那可能是OpenSSL库没编译正确，或者链接时没正确关联。

5. 给OpenSSH的配置加更明确的依赖路径 #

你当前的OpenSSH配置没明确指定OpenSSL和zlib的路径，可能不小心链接到了系统默认的库：

• 修改configure命令，明确指定依赖库的位置：

  ./configure CC="mips64-octeon-linux-gnu-gcc" \
    --with-cflags="-mabi=n32 -I/mnt/cf/include" \
    --with-ldflags="-mabi=n32 -L/mnt/cf/lib -pthread" \
    --with-openssl=/mnt/cf \
    --with-zlib=/mnt/cf \
    --prefix=/mnt/cf
  

  这样能确保OpenSSH链接到你自己编译的N32版本的OpenSSL和zlib，而不是系统里的其他ABI版本。

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