同项目引用头文件时出现未定义引用错误的排查

这个问题的核心非常明确：你的测试程序harness没有链接到你编译出来的包含generate函数的共享库，所以链接器找不到这个函数的实现符号。下面是具体的排查和修复步骤：

1. 关键修复：在CMake中链接你的共享库 #

你当前的target_link_libraries只给harness添加了${CV_LIBS}，完全没有指定要链接你自己的共享库。假设你在上级CMakeLists.txt中编译共享库时，用了类似这样的代码：

add_library(your_shared_lib SHARED src/generate.cpp) # 替换成你的库目标名和实际源文件

那么在测试目录的CMakeLists.txt里，你需要把这个库目标链接到harness上：

target_link_libraries(harness PRIVATE your_shared_lib ${CV_LIBS})

因为你是通过add_subdirectory(test)引入测试目录的，上级目录的库目标在测试目录中是可见的，直接用目标名链接即可（这比手动指定库文件路径更可靠，也更符合CMake的最佳实践）。

2. 可选但推荐：规范共享库的符号导出（跨平台兼容） #

虽然Linux/macOS下默认会导出所有符号，但Windows下需要显式标记要导出的函数，否则链接时也会出现类似的未定义引用问题。建议在你的extract.hpp中添加导出宏，确保函数能被正确识别：

// 在extract.hpp的开头添加
#ifdef _WIN32
#if defined(BUILD_SHARED_LIBS) || defined(YOUR_LIB_EXPORTS)
#define YOUR_LIB_API __declspec(dllexport)
#else
#define YOUR_LIB_API __declspec(dllimport)
#endif
#else
// Linux/macOS 不需要特殊标记，直接空宏即可
#define YOUR_LIB_API
#endif

// 用宏修饰函数声明
YOUR_LIB_API int generate(const char* infile, std::vector<uint8_t> &detection, int another_flag);

这样不管在哪个平台，共享库的函数都能被测试程序正确引用。

3. 额外排查点 #

• 确认你的共享库已经成功编译：检查构建目录下是否生成了对应的.so（Linux）、.dylib（macOS）或.dll/.lib（Windows）文件。
• 确认函数签名完全匹配：从报错信息看，char const*和const char*是等价的，std::vector<unsigned char>和std::vector<uint8_t>也是等价的（因为uint8_t本质就是unsigned char的typedef），所以签名问题可以直接排除。

最后，清理之前的构建缓存，重新运行CMake和编译流程，应该就能解决这个链接错误了。

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