CMake构建自定义共享库时出现未定义引用问题

交叉编译场景下的链接问题确实容易踩坑，我整理几个你可能还没尝试的方向，帮你定位问题：

1. 修正CMake链接库的规范写法 #

你当前在FooBar的CMakeLists.txt里用了-L${Foo} -L${Bar} -L${Curl}，这是典型的错误用法：-L是指定库的搜索路径，而非链接库本身，链接库应该用-l（小写L）。更符合CMake规范的是直接使用find_library返回的变量，因为它已经帮你找到了库的完整路径或正确名称。

修改FooBar的target_link_libraries部分：

# 替换原来的-L写法，直接链接找到的库
target_link_libraries(FooBar PRIVATE 
    Threads::Threads
    ${Foo}
    ${Bar}
    ${Curl}
)

这样CMake会自动处理库的路径和链接参数，避免手动写-L/-l导致的路径或名称错误。

2. 确保依赖库的传递性（让可执行程序自动继承依赖） #

共享库的依赖需要正确传递给上层可执行程序，你可以通过PUBLIC关键字或INTERFACE_LINK_LIBRARIES让FooBar把它的依赖暴露给链接它的目标：

# 方式一：用PUBLIC关键字直接传递依赖
target_link_libraries(FooBar PUBLIC 
    Threads::Threads
    ${Foo}
    ${Bar}
    ${Curl}
)

# 方式二：显式设置INTERFACE属性
set_target_properties(FooBar PROPERTIES
    INTERFACE_LINK_LIBRARIES "${Foo};${Bar};${Curl};Threads::Threads"
)

这样当FooBarExe链接FooBar时，CMake会自动把Bar、Foo等依赖库也链接进去，无需手动在可执行程序的CMake里重复添加。

3. 检查Bar库的编译属性（位置无关代码PIC） #

因为FooBar是共享库，链接到它的静态库必须是**位置无关代码（PIC）**编译的。如果Bar是静态库，你需要确认它在编译时添加了-fPIC参数（GCC）或对应的编译选项：

• 如果Bar是你自己编译的，在它的CMakeLists.txt里添加set(CMAKE_POSITION_INDEPENDENT_CODE ON)
• 如果是第三方预编译库，需要确认它是针对目标平台以PIC方式编译的

4. 验证符号名是否存在名字损坏（C/C++混合调用问题） #

如果Bar库是C语言编写的，而FooBar用C调用它的函数，必须在包含Bar的头文件时用extern "C"包裹，否则C编译器会对函数名进行名字修饰（mangling），导致链接时找不到对应符号：

// 在FooBar的代码中包含Bar头文件时
extern "C" {
#include "bar.h"
}

你可以用nm命令验证符号名是否一致：

# 检查Bar库中的符号（假设是libbar.so）
nm -D libbar.so | grep "function"
# 检查FooBar.so中的未定义符号
nm -D FooBar.so | grep "U function"

如果两者名字不一致（比如C++的名字是_Z8functionv而C的是function），就说明是名字修饰的问题。

5. 确认交叉编译工具链的正确性 #

交叉编译时很容易误用到主机系统的库，你需要检查：

• 是否正确设置了CMAKE_TOOLCHAIN_FILE，指向目标平台的工具链文件
• CMAKE_SYSROOT是否指向目标系统的根文件系统，确保find_library找到的是目标平台的Bar库，而非主机上的库
• 可以在find_library时指定PATHS参数，明确指向目标平台的库路径：

find_library(Bar NAMES bar PATHS /path/to/target/sysroot/usr/lib)

6. 测试显式链接Bar库到可执行程序 #

如果以上方法都无效，你可以尝试在FooBarExe的CMakeLists.txt中显式链接Bar库，测试是否能解决问题：

target_link_libraries(FooBarExe PRIVATE FooBar ${Bar})

如果这样能解决，说明依赖传递没有正确设置，回到步骤2修复即可。

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