Windows下MinGW-w64生成DLL时-fPIC常可省略，因x86_64默认生成位置无关代码，x86下GCC链接-shared时自动补全；真正关键的是必须用__declspec(dllexport)显式导出符号，否则DLL无可用函数。
Windows 下用 GCC（如 MinGW-w64）生成动态库，核心是 -shared + -fPIC，但要注意 Windows 不需要 -fPIC（x86_64 默认支持，x86 可省略），且必须导出符号才能被外部调用。
为什么 Windows 下 -fPIC 常可省略
MinGW-w64 的 GCC 在 x86_64 目标下默认生成位置无关代码，-fPIC 不是强制要求；x86（32 位）下虽理论上需要，但实际链接 -shared 时 GCC 会自动补全。强行加 -fPIC 不报错，但冗余——尤其对简单函数库反而可能引入不必要的 GOT/PLT 开销。
- 验证方式：
gcc -c add.c后用objdump -d add.o | grep call，若无绝对地址跳转，说明已满足共享库要求 - 真正必须的是：所有要被外部调用的函数，得显式声明为
__declspec(dllexport)
__declspec(dllexport) 必须加在头文件和实现中
Windows 动态库（DLL）不靠链接器自动导出符号，不加导出声明，libxxx.dll 里就没有可用函数——哪怕编译通过，运行时 LoadLibrary 或链接 -lxxx 都会找不到符号。
- 正确写法（
add.h）：#ifdef BUILDING_ADD_DLL #define ADD_API __declspec(dllexport) #else #define ADD_API __declspec(dllimport) #endif ADD_API int add(int a, int b);
- 编译时定义宏：
gcc -DBUILDING_ADD_DLL -c add.c，否则add.o里不会导出 - 漏掉宏定义或拼错（如
BUILD_ADD_DLL）→ 生成的 DLL 导出表为空 →ldd test.exe显示add.dll => not found（其实是 found 但没符号）
生成 DLL 和对应 import lib 的完整命令链
MinGW-w64 的 gcc -shared 默认同时生成 DLL 和隐式 import lib（libxxx.a），后者供链接阶段使用，不是 Windows 原生的 .lib 文件，但行为等效。
- 生成目标文件：
gcc -DBUILDING_ADD_DLL -c add.c -o add.o - 生成 DLL 和 import lib：
gcc -shared -o add.dll add.o→ 输出add.dll+libadd.a - 链接可执行程序：
gcc main.c -L. -ladd -o test.exe（注意：不是-ladddll，也不是add.lib） - 运行前无需设
PATH？错。必须确保add.dll在test.exe同目录，或在系统PATH中，否则报错The program can't start because add.dll is missing
容易被忽略的 ABI 和架构匹配问题
Windows 下 DLL 调用失败，近三成原因是架构错配：用 x86_64 GCC 编的 DLL，被 x86 程序链接，或反过来。错误不提示“架构不匹配”，只报 undefined reference to 'add' 或运行时崩溃。
- 检查方法：
file add.dll（Linux/Msys2）或dumpbin /headers add.dll（Windows SDK）看 machine 字段 - 强制指定目标架构：
gcc -m64 -shared -o add.dll add.o（64 位），gcc -m32 -shared -o add.dll add.o（32 位） - 头文件中避免用
long、size_t等平台相关类型，改用int32_t、uintptr_t保 ABI 稳定
