CentOS7下用预编译Makefile链接时遇-lcurl及未定义引用问题求助

咱们一步步拆解你遇到的两个问题：

第一个问题：链接器找不到-lcurl #

当你看到/bin/ld: cannot find -lcurl时，核心原因是链接器ld在搜索路径里找不到不带版本号的libcurl.so软链接——因为-lcurl这个参数会让ld默认查找libcurl.so，而不是你系统里已有的带版本号的libcurl.so.4或libcurl.so.4.3.0。

在CentOS 7 64位系统中，标准的解决方式是：

• 安装libcurl-devel包（你已经这么做了），这个包会自动在/usr/lib64/目录下创建libcurl.so指向libcurl.so.4.3.0的软链接
• 如果安装后还是没有，你可以手动创建：

  sudo ln -s /usr/lib64/libcurl.so.4.3.0 /usr/lib64/libcurl.so
  

这一步你已经完成，所以第一个错误消失，但引出了新的未定义引用问题。

第二个问题：大量C++相关的未定义引用 #

你看到的undefined reference to 'operator delete(void*, unsigned long)'这类错误，本质是C++ ABI（应用二进制接口）不匹配，或者链接时库的顺序/依赖缺失。结合你的环境细节，大概率是这几个原因：

1. Xerces-C静态库的编译环境和当前系统不兼容 #

从路径能看出来，你用的是自己编译安装到/usr/local/lib的静态库libxerces-c.a。如果这个库是用比CentOS 7默认GCC 4.8.5更高版本的编译器编译的，就会出现ABI不兼容——高版本GCC的C++标准库实现（比如operator delete的签名）和4.8.5有差异，导致链接时找不到对应符号。

要复刻原始环境的话，你需要：

• 确认原始环境用的是CentOS 7默认的GCC 4.8.5
• 用这个版本的GCC重新编译Xerces-C 3.1.1，替换掉现在的/usr/local/lib/libxerces-c.a

2. 链接库的顺序或依赖缺失 #

静态库需要把依赖的库放在链接顺序的后面，你的Makefile里把libxerces-c.a放在-lcurl前面，而Xerces-C作为C++库，依赖系统的libstdc++库，但Makefile里没有显式声明。

因为你不能修改Makefile，可以通过环境变量追加依赖：

export EXTRALIBS="$EXTRALIBS -lstdc++"

然后重新运行make，让链接器自动补上C++标准库的依赖。

3. 链接器的库搜索路径优先级问题 #

链接器可能先搜索了/usr/local/lib（你的Xerces-C所在目录），而没有优先使用系统/usr/lib64下的库，导致依赖解析错误。你可以调整环境变量让系统库优先：

export LIBRARY_PATH=/usr/lib64:$LIBRARY_PATH

再执行编译命令。

复刻原始环境的关键要点 #

如果要完全适配这个Makefile的原始环境，大概率满足以下几点：

• 系统是CentOS 7 64位，默认安装了libcurl-devel包
• Xerces-C是用系统默认GCC 4.8.5编译的，且以动态库形式存在（链接时用-lxerces-c而非直接指定静态库路径）
• 链接时自动包含了C++标准库的依赖

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