Cygwin/MSYS2下MinGW64静态编译C程序仍依赖系统DLL问题

Windows平台不存在和Linux下完全等价的、零任何DLL依赖的用户态C可执行文件，你当前的编译结果是正常的，不是参数配置错误。

Linux下给gcc加--static参数即可实现完全静态链接，本质是链接器将glibc等所有依赖库的代码全部打包进二进制，程序启动时不需要加载任何外部动态库。但Windows平台的PE可执行文件有本质区别：

• 所有Windows用户态程序必然依赖系统核心DLL，包括你ldd输出中看到的ntdll.dll、KERNEL32.DLL、KERNELBASE.dll、msvcrt.dll，这些是Windows操作系统的原生组件，随系统自带，不存在“静态打包进程序”的官方实现——MinGW工具链本身就不提供这些系统库的静态版本，无论你调整什么编译参数，都不可能把这些系统级依赖完全编进exe里。
• 你输出里的aswhook.dll是AVG杀毒软件的全局注入DLL，和你的程序本身没有任何链接关系，关闭杀毒软件或者换个没有安全软件注入的环境再检测，这个条目就会消失。

你加--static参数的编译操作已经达到了MinGW环境下静态编译的标准效果：

• 程序已经静态链接了所有MinGW自带的运行时库，包括libgcc、libstdc++、libwinpthread等，不会依赖任何随MinGW分发的第三方DLL
• 编译出的exe可以直接拷贝到其他相同架构的Windows设备上运行，不需要额外安装C运行时或者MinGW环境
• 你看到的系统DLL依赖是所有Windows程序的共性，哪怕是用微软官方MSVC编译器编译的程序，也同样会依赖这些核心系统DLL，不存在例外。

网上流传的额外加-static-libgcc、-static-libstdc++之类的参数组合，本质都是在控制MinGW自有运行时的链接方式，你使用--static参数时已经默认开启了这些静态链接选项，重复添加不会改变系统DLL依赖的结果。你在Cygwin、MSYS2环境下测试得到相同结果是正常现象，不同环境下的MinGW工具链都遵循Windows平台的PE加载规则，不可能突破系统机制限制。

如果强行追求完全无任何DLL依赖，只能放弃Windows原生用户态开发模型，自行实现系统调用层、绕过Win32子系统加载逻辑，这种方案没有实用价值，也无法直接使用标准库的printf等函数。

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