Windows下CTypes调用Cygwin GCC编译的64位C DLL报WinError126求助

咱来拆解这个问题——你遇到的[WinError 126]虽然提示“找不到模块”，但既然路径已经验证过，90%的概率是Cygwin编译的DLL依赖了隐藏的运行时库，而不是你的代码或者路径问题。下面给你一步步排查和解决的方案：

1. 核心原因：Cygwin GCC编译的DLL依赖cygwin1.dll #

Cygwin的GCC本质上是在Windows上模拟POSIX环境，默认编译出的DLL不是纯Windows原生的，必须依赖Cygwin的核心运行时库cygwin1.dll才能运行。你用gcc -M只能看到编译阶段的静态依赖，看不到这种动态链接的系统级依赖，所以才会误以为“无依赖”。

解决办法： #

• 方法A：补充Cygwin运行时库
  找到你Cygwin安装目录下的bin文件夹（比如C:\cygwin64\bin），把里面的cygwin1.dll复制到你的目标DLL同一目录，或者把这个bin路径添加到系统的PATH环境变量里。这样系统加载器就能找到依赖的运行时库了。
• 方法B：改用MinGW-w64编译原生Windows DLL
  如果你不想依赖Cygwin环境，直接用MinGW-w64的编译器编译，它生成的是纯Windows原生DLL，不需要额外的Cygwin runtime。编译命令大概是这样：

  x86_64-w64-mingw32-gcc -shared -o your_dll.dll your_source.c -Wl,--out-implib=your_dll.lib
  

  记得要给需要导出的函数加上__declspec(dllexport)标记，或者用.def文件声明导出函数，避免名字 mangling（比如C++的函数名变形）。

2. 验证DLL位数与Python匹配 #

别忽略这个基础点：你编译的是64位DLL，必须确保你的Python也是64位版本。32位Python加载64位DLL时，系统加载器会直接返回“找不到模块”的错误（虽然文件确实存在）。

验证Python位数的方法：打开Python终端输入：

import sys
print(sys.maxsize > 2**32)

返回True就是64位，False则是32位，得和你的DLL位数对应上。

3. 检查DLL的导出函数是否正常 #

虽然你现在是加载失败，但有时候导出函数的问题也会间接导致加载异常（比如某些编译器的特殊处理）。可以用工具检查DLL的导出表：

• 用Visual Studio自带的dumpbin工具：

  dumpbin /exports your_dll.dll
  

• 用Cygwin的nm命令：

  nm -D your_dll.dll
  

确保你要调用的函数已经正确导出，没有被C名字 mangling（如果是C代码，记得用extern "C"包裹函数声明）。

4. 用工具排查具体依赖缺失 #

如果上面的方法都没解决，就用工具精准定位：

• Dependency Walker：打开你的DLL，它会列出所有依赖的库，红色标记的就是找不到的文件，直接看缺失的是什么。
• Process Monitor：启动软件后过滤进程为python.exe，然后运行你的ctypes调用代码，看日志里的“File Not Found”记录，就能找到系统加载DLL时到底找不到哪个文件。

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