MSVC链接器下ODR违反与extern "C"的行为差异疑问

问题背景 #

我测试Windows link.exe时，想验证它遇到ODR（单定义规则）违反时的反应——预期程序中存在同一函数dynamic_func的两个定义（一个来自DLL）时，链接器会报错。

场景1：触发LNK2005符号重定义错误 #

我编写了以下代码：

main.cpp #

#include "dynamic_lib.h"
#include "static_lib.h"

int main()
{
    dynamic_func();
    static_func();

    return 0;
}

dynamic_lib.h #

#ifndef DYNAMIC_LIB_H
#define DYNAMIC_LIB_H

extern "C" {

#ifdef HEADER_ONLY
#   define INLINE inline
#   define DYNAMIC_LIB_API
#else
#   define INLINE
#   ifdef _WIN32
#       ifdef BUILDING_LIB
#           define DYNAMIC_LIB_API __declspec(dllexport)
#       else
#           define DYNAMIC_LIB_API __declspec(dllimport)
#       endif /* BUILDING_LIB */
#   else
#       define DYNAMIC_LIB_API
#   endif /* _WIN32 */
#endif /* HEADER_ONLY */

DYNAMIC_LIB_API void dynamic_func();

}

#ifdef HEADER_ONLY
#   include "dynamic_lib.cpp"
#endif

#endif /* DYNAMIC_LIB_H */

dynamic_lib.cpp #

#include "dynamic_lib.h"

INLINE void dynamic_func()
{}

static_lib.h #

#ifndef STATIC_LIB_H
#define STATIC_LIB_H

extern "C" {

void static_func();

}

#endif /* STATIC_LIB_H */

static_lib.cpp #

#include "static_lib.h"
#include "dynamic_lib.h"

void static_func()
{
    dynamic_func();
}

CMakeLists.txt #

cmake_minimum_required(VERSION 3.20.0 FATAL_ERROR)

project(Test CXX)

set(CMAKE_CXX_STANDARD 20)

add_library(dynamic_lib SHARED
    dynamic_lib.cpp
)

target_compile_definitions(dynamic_lib PRIVATE BUILDING_LIB)

add_library(static_lib STATIC
    static_lib.cpp
)

target_compile_definitions(static_lib PRIVATE HEADER_ONLY)

add_executable(main
    main.cpp
)

target_link_libraries(main PUBLIC
    dynamic_lib
    static_lib
)

尝试链接main.exe时，正确触发了dynamic_func的LNK2005符号重定义错误。

场景2：链接正常完成 #

修改static_lib.cpp，直接定义dynamic_func：

#include "static_lib.h"

void dynamic_func()
{}

void static_func()
{
    dynamic_func();
}

此时链接步骤能正常完成，没有报错。

关键观察 #

• 两种场景下，编译器和链接器的调用参数完全一致
• 场景1在GCC和Clang上可以正常构建
• 分析预处理输出后发现：正是extern "C"块中的dynamic_func声明导致场景1失败；给场景2的代码添加该声明后，也会触发相同的LNK2005错误

原因解析 #

1. 符号命名差异 #

extern "C"会强制函数使用无名字修饰的C风格符号名，而普通C++函数会生成带名字修饰的符号（包含参数类型、命名空间等信息）：

• 场景1中，static_lib通过头文件模式引入的dynamic_func是extern "C"的inline定义，符号名为_dynamic_func（Windows下C符号的命名规则）；DLL导出的dynamic_func也是extern "C"的，符号名完全一致。链接器看到两个相同的强符号，直接触发重定义错误。
• 场景2中，static_lib.cpp直接定义的void dynamic_func()没有extern "C"修饰，生成的是C风格的符号（比如?dynamic_func@@YAXXZ），和DLL导出的C风格符号完全不同。链接器认为这是两个不同的函数，因此不会报错。此时main.cpp调用的是DLL导入的extern "C"版本，而static_lib内部调用的是自己定义的C版本，两者实际是独立的函数。

2. Windows链接器对inline和extern "C"的特殊处理 #

C++标准允许inline函数存在多个定义（只要内容完全一致），但Windows link.exe对extern "C"的inline函数处理更严格：

• 当extern "C"的inline函数同时存在__declspec(dllimport)声明（main.cpp中）和本地定义（static_lib中）时，链接器不会将本地定义视为弱符号，而是将其视为与DLL导出符号冲突的强符号。
• GCC/Clang则遵循C++标准，允许这种符合条件的inline多定义，因此场景1在这些编译器下可以正常构建。

总结理解误区 #

1. 场景等价性误解：两种场景看似都是定义了dynamic_func，但场景1是extern "C"符号，场景2是C++符号，两者的符号标识完全不同，链接器的处理逻辑自然不同。
2. 忽略Windows链接器的特殊性：Windows link.exe对extern "C"符号的重定义检查比GCC/Clang更严格，不支持C++标准中inline函数多定义的例外情况（涉及DLL导出时）。
3. inline的作用混淆：extern "C"修饰的inline函数在Windows下不会被视为弱符号，无法和同符号的DLL导出共存，这和普通C++ inline函数的处理逻辑有差异。

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