从AIX移植自制软件至Red Hat Enterprise Linux 7.8时遇链接阶段‘undefined reference’错误求助

从你的描述来看，这个问题主要是GCC链接器的符号解析顺序和C/C++混合编译的符号兼容性导致的——毕竟AIX的xlC和GCC的行为差异不小，我帮你一步步排查：

1. 先修正最可能的问题：库链接顺序 #

GCC的ld链接器是从左到右按顺序解析符号，如果某个库依赖另一个库的符号，那么依赖库要放在被依赖库的前面。你的链接命令里-lmsi在-latmi前面，但libatmi.so需要调用libmsi.so里的Msi_tpreturn等符号，这就会导致链接器先处理libmsi.so，之后处理libatmi.so时发现未定义符号，但后面已经没有能提供这些符号的库了。

把链接命令里的库顺序调整一下，把-latmi移到-lmsi前面，同时修正错误的-DWall（改成-Wall，-D是用来定义宏的，会错误地生成一个名为Wall的宏）：

gcc -Wall -o bin/pingsrv -DUNIX -I. -g -D_THREAD_SAFE -D_LARGEFILE64_SOURCE -I/home/vgi/git/msi-tools/ping/server/target/msi/include/yaml-cpp -I/home/vgi/git/msi-tools/ping/server/target/msi/include/apr-1 -I/home/vgi/git/msi-tools/ping/server/target/msi/include/activemq-cpp-3.9.4 -I/home/vgi/git/msi-tools/ping/server/target/msi/include /tmp/MsiServices.o ./pingsrv.c -L/home/vgi/git/msi-tools/ping/server/target/msi/lib -latmi -lmsi -lactivemq-cpp -llog4cxx -lapr-1 -laprutil-1 -lexpat -lstdc++ -lyaml-cpp

2. 验证C/C++混合编译的符号修饰是否正确 #

虽然你的头文件里加了extern "C"，但要确认libmsi.so里的符号是否真的是C风格（没有被C++编译器修饰）。用nm命令检查：

nm -D /home/vgi/git/msi-tools/ping/server/target/msi/lib/libmsi.so | grep -E "Msi_tpreturn|Msi_tpcall|Msi_userlog"

如果输出是类似下面的格式，说明符号是C风格的，没问题：

0000000000012345 T Msi_tpreturn
0000000000012350 T Msi_tpcall
0000000000012355 T Msi_userlog

如果输出是类似_Z12Msi_tpreturnP12MsiSchedulerilll这种被修饰的名字，说明extern "C"没有生效。这时候可以直接在MsiScheduler.cpp的函数定义前加上extern "C"，强制让编译器按C风格导出符号：

extern "C" void Msi_tpreturn(MsiScheduler * c,int ret,long code,char *data,long len,long flags) {
    // 你的函数实现
}

3. 解决msi::service::optarg未定义的问题 #

这个错误是说libmsi.so里找不到C++静态变量msi::service::optarg的定义，你需要检查：

• 这个变量的定义是否存在于某个cpp文件中，比如是否有类似这样的代码：

  namespace msi {
  namespace service {
      char* optarg = nullptr; // 或者其他初始值
  }
  }
  

• 定义这个变量的cpp文件是否被编译成目标文件，并链接到了libmsi.so里。从你提供的libmsi.so构建命令来看，MsiService.o已经被包含了，所以大概率是变量的声明和定义不匹配（比如命名空间写错了，或者声明是extern但没有定义）。

额外提示：AIX和GCC链接器的差异 #

AIX的xlC链接器默认会多次扫描库来解析符号，而GCC的ld默认只会扫描一次，所以在AIX上能正常链接的顺序，到GCC下就会出问题。调整库顺序是解决这类跨平台链接问题的核心。

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