Clang在Windows下生成.dll无需-fPIC，因PE/COFF不强制位置无关代码；应使用clang++ -shared（C++推荐）或clang -shared（C或extern "C"包裹时），并用__declspec(dllexport)显式导出符号。
Clang在Windows下生成.dll必须加-fPIC吗？
不需要。Windows的PE/COFF格式不强制要求位置无关代码，-fPIC在Windows下被Clang忽略（或发出警告），加了也没用。这点和Linux/macOS完全不同——别照搬Linux命令。
正确命令是clang -shared还是clang++ -shared？
两者都行，但关键看源码语言和符号导出方式：
- 纯C代码：用
clang -shared即可 - C++代码且需导出函数：必须用
clang++ -shared，否则C++ name mangling会导致Java/JNI或C#无法找到符号 - 若C++中用了
extern "C"包裹函数声明，则clang -shared也能用，但容易漏写或包错范围
推荐统一用 clang++ -shared，避免因语言混用踩坑。
如何让函数能被外部调用（比如Java System.loadLibrary）？
Windows下DLL默认不导出任何符号，必须显式声明。常见错误是编译成功但Java报 UnsatisfiedLinkError: no xxx in java.library.path 或运行时报找不到方法。
- 用
__declspec(dllexport)标记要导出的函数或类（头文件中加宏适配） - 不要依赖
extern "C"就以为自动导出了——它只解决name mangling，不解决符号可见性 - 示例：
extern "C" __declspec(dllexport) int add(int a, int b) { return a + b; } - 验证导出：编译后用
dumpbin /exports libxxx.dll查看符号是否在列表里
链接时找不到libclang.dll或找不到入口点？
Clang本身不自带Windows运行时DLL（如libclang.dll），但生成DLL时若链接了LLVM相关库，就得确保运行时能找到它们。更常见的是自己写的DLL被调用时崩溃，原因往往是：
- 目标平台不匹配：Clang默认生成x86 DLL，但Java或宿主程序是x64——用
--target=x86_64-pc-windows-msvc显式指定 - MSVCRT版本冲突：Clang默认用UCRT，而老项目可能依赖MSVCR120.dll等；加
-D_MT -D_DLL并链接对应CRT（如-lmsvcr120）可缓解 - 入口点缺失：没写
DllMain不会报错，但某些工具（如JNI）对初始化有隐式依赖；简单起见，不写也行，但别假设它会被自动调用
最稳妥的做法：用 clang++ --target=x86_64-pc-windows-msvc -shared 编译，用 dumpbin 确认导出符号，再用 Dependency Walker 或 ldd（MinGW版）检查依赖链——别只看编译过没过。
