如何编译时验证所有符号是否在 Linux 共享对象库中完全定义

问：

最近，我意识到，如果您尝试引用未定义的函数/变量，linux 共享对象库不会编译失败。这些符号确实需要声明，但不需要定义。我更熟悉 Windows DLL，而不是 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__);

    // The below ifdef block compiles just fine as a linux shared object binary.
    // It does *NOT* compile as a windows DLL.
#ifdef TRY_COMPILE_UNDEFINED_FUNC
    undefined_variable += 1;
    undefined_function();
#endif // TRY_COMPILE_UNDEFINED_FUNC
}

#ifdef __cplusplus
}
#endif // __cplusplus

我想知道是否有一些最低限度的黑客方法可以从 Windows DLL 中复制具有 linux 共享对象库的“编译失败”行为。在不陷入杂草的情况下，我正在构建的共享对象库是在延迟加载而不是编译的上下文中使用，因此现在似乎捕获这些问题的唯一方法是在运行时，这很容易出错。

我有两个想法还没有完全实现：

1. 将未使用的可执行文件添加到针对共享库进行编译的构建中。这是不理想的，因为它容易出错，并且依赖于我更新可执行文件以实际链接到共享库的所有不同部分（例如，通过调用导出的函数等等）
2. 使用该实用程序转储所有未解析的符号，但也包括来自 libc 等内容的未解析符号nm