如何在编译阶段验证Linux共享对象库中所有符号已完全定义？

最近发现Linux共享对象库在引用未定义的函数/变量时不会编译失败，只要声明这些符号就行。但Windows DLL不允许这类未定义引用，这一点挺意外的。

附示例代码：

#ifdef __cplusplus
extern "C" {
#endif // __cplusplus

#define TRY_COMPILE_UNDEFINED_FUNC

#ifdef TRY_COMPILE_UNDEFINED_FUNC
extern int undefined_variable;
void undefined_function();
#endif // TRY_COMPILE_UNDEFINED_FUNC

void SharedLibTest_TestFunc()
{
    printf("%s executed.\n", __FUNCTION__);

    // 以下代码块编译为Linux共享对象可正常通过
    // 但编译为Windows DLL时无法通过
#ifdef TRY_COMPILE_UNDEFINED_FUNC
    undefined_variable += 1;
    undefined_function();
#endif // TRY_COMPILE_UNDEFINED_FUNC
}

#ifdef __cplusplus
}
#endif // __cplusplus

现在需要让Linux共享对象库实现类似Windows DLL的编译时检测未定义符号并报错终止的行为。当前场景下共享对象是延迟加载且不参与编译链接的，问题只能在运行时发现，很容易出错。

之前试过两种效果不好的方法：

• 在构建流程里加一个没用的可执行文件，链接这个共享库。但这种方法容易出问题，还得更新可执行文件来确保覆盖共享库的所有部分（比如调用导出函数）
• 用nm工具导出所有未解析符号，但结果会包含libc等系统库的未解析符号，没法精准定位自己代码里的问题。

方法1：链接器选项强制检查未定义符号 #

这是最简便直接的方法——编译共享对象时，给ld加-z defs（或等价的--no-undefined）选项，让链接器遇到未解析符号直接报错，终止编译流程。

比如用GCC编译时：

gcc -shared -o libtest.so test.c -z defs

如果代码里有undefined_variable和undefined_function这类未定义符号，链接器会直接输出类似错误：

undefined reference to `undefined_variable'
undefined reference to `undefined_function'

完全达到Windows DLL的编译时检测效果。

如果用CMake构建项目，直接在目标设置里加：

target_link_options(your_shared_lib PRIVATE "-z defs")

方法2：精准控制符号范围（可选） #

如果某些系统库的符号确实需要延迟解析，可以用-z undefs允许未定义符号，但配合--version-script来限制允许未定义的符号范围。比如写一个版本脚本version.lds：

{
    global: SharedLibTest_TestFunc;
    local: *;
};

然后编译时：

gcc -shared -o libtest.so test.c -z defs -Wl,--version-script=version.lds

这种方式能精准控制哪些符号需要导出，同时强制检查所有其他符号的定义。

方法3：优化nm工具的使用（辅助手段） #

如果必须用nm，可以过滤掉系统库的符号，只保留自己代码里的未定义符号。比如：

nm -D libtest.so | grep ' U ' | grep -v -E 'printf|__libc_start_main'

不过这种方法需要手动维护要排除的系统符号列表，不如-z defs可靠，只能作为辅助检查手段。

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