Windows下Julia调用Cygwin编译DLL时dlopen致工作区重启求助

为什么会出现这个问题？ #

这本质是Cygwin编译的DLL和Windows原生Julia的运行时环境不兼容导致的进程崩溃：

• Cygwin的gcc编译出来的DLL必须依赖cygwin1.dll——这个库是Cygwin用来模拟POSIX/Unix环境的核心组件，它会在进程内构建一套独立的类Unix运行环境。
• 而Julia v0.6.2的Windows官方二进制是基于MinGW-w64编译的，它依赖的是Windows原生的C运行时（比如msvcrt.dll），和Cygwin的虚拟环境完全不兼容。
• 当你用dlopen加载Cygwin DLL时，cygwin1.dll会试图注入Julia进程，这种跨运行时的环境入侵直接触发了进程崩溃，表现就是Julia工作区突然重启、所有变量丢失。而且这个问题确实是Windows特有，因为Ubuntu本身就是POSIX环境，不存在这类冲突。

可行的解决办法 #

按可靠性和易用性排序，给你几个方案：

1. 用MinGW-w64重新编译C代码（最推荐）

放弃Cygwin，改用MinGW-w64编译出Windows原生的DLL，这是从根源解决冲突的办法：

• 先安装MinGW-w64：可以用官方安装器，或者通过Chocolatey这类包管理工具一键安装。
• 用MinGW-w64的gcc编译你的C代码，生成不依赖Cygwin的DLL：

  # 替换成你的源文件名和想要输出的DLL名
  x86_64-w64-mingw32-gcc -shared -o my_native_dll.dll my_source.c -Wl,--export-all-symbols
  

• 编译完成后，直接在Julia里用dlopen加载这个DLL，就不会再出现崩溃重启的问题了。

2. 在Cygwin环境里运行Julia

如果必须用Cygwin编译的DLL，可以试试在Cygwin终端里运行Julia：

• 从Cygwin的包管理器里安装Julia（注意找对应v0.6.2的版本，可能需要手动下载适配Cygwin的编译包）。
• 启动Cygwin终端，在里面运行Julia——此时Julia进程本身就处于Cygwin的运行时环境中，加载同环境编译的DLL就不会有冲突了。

3. 手动处理依赖（不推荐）

如果一定要在原生Windows Julia里加载Cygwin DLL，可以先检查DLL的依赖：

• 用Visual Studio的dumpbin /dependents your_cygwin_dll.dll或者Cygwin的ldd工具，确认cygwin1.dll在系统PATH里。
• 但即使PATH配置正确，由于两种运行时的本质冲突，还是大概率会崩溃，所以这个方案只适合临时测试，不建议长期使用。

额外建议 #

• Julia v0.6.2是2018年的老版本了，对Windows的兼容性不如新的v1.x系列，能升级的话尽量升级，新版本的C交互支持更稳定。
• 测试新编译的DLL时，先写个简单的测试函数（比如返回一个整数）用ccall调用，验证没问题再用复杂逻辑，这样更容易排查问题。

内容的提问来源于stack exchange，提问作者Pedro H. N. Vieira