我来帮你一步步排查这个链接器错误，这类问题通常和库的链接顺序、搜索路径或者C/C++名字修饰差异有关，咱们逐个解决：

1. 调整编译命令的库顺序（最常见原因） #

你的编译命令把-lcurl放在了目标文件前面，这会导致链接器处理顺序错误：链接器是从左到右扫描文件，先处理-lcurl时还没有遇到未定义的curl_global_init符号，所以不会保留库中的对应符号；等后面处理tz.o和main.o时，再找这个符号就找不到了。

把库参数移到目标文件之后：

g++ -std=c++17 tz.o main.o -lcurl

2. 指定链接器搜索/usr/local/lib路径 #

Ubuntu默认的链接器搜索路径可能不包含/usr/local/lib（系统默认优先搜/usr/lib），所以需要用-L参数明确告诉链接器去这个目录找库：

g++ -std=c++17 tz.o main.o -L/usr/local/lib -lcurl

如果希望运行时也优先使用/usr/local/lib下的libcurl，可以加上-Wl,-rpath=/usr/local/lib参数，确保程序运行时能找到正确的库：

g++ -std=c++17 tz.o main.o -L/usr/local/lib -Wl,-rpath=/usr/local/lib -lcurl

3. 检查C++代码是否正确处理C库的名字修饰 #

libcurl是C语言编写的库，而C++会对函数名进行名字修饰（Name Mangling），如果你的代码没有用extern "C"包裹curl的头文件，编译器会生成修饰后的符号，和C库导出的原始符号不匹配，导致链接失败。

在你的C++代码中，修改curl头文件的包含方式：

extern "C" {
#include <curl/curl.h>
}

4. 验证库与目标文件的架构一致性 #

确保你的目标文件（tz.o、main.o）和/usr/local/lib/libcurl.so的架构一致（都是32位或64位）：

• 检查库的架构：

  file /usr/local/lib/libcurl.so
  

• 检查目标文件的架构：

  file tz.o
  

如果两者架构不匹配，需要重新编译对应架构的libcurl或调整程序的编译架构。

5. 确认libcurl的版本与符号匹配 #

虽然你用nm -D看到了T前缀的curl_global_init，可以再确认一下符号的完整名称是否和代码中调用的一致：

nm -D /usr/local/lib/libcurl.so | grep curl_global_init

如果输出的符号是curl_global_init（没有额外的修饰字符），那说明库本身是正常导出的，问题还是出在前面几个步骤里。

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