Windows环境下fast_tls编译失败问题排查与解决方案

问题表现 #

在Windows 10系统上按教程构建Phoenix框架的STUN服务器时，编译依赖组件fast_tls环节抛出异常。
前期参照MacOS下openssl头文件相关问题的解决思路，配置了指向msys64路径的LDFLAGS、CFLAGS、CPPFLAGS环境变量后，先后尝试两种编译方式均失败：

• 直接在Elixir项目目录执行mix compile：系统自动调用MSVC的cl.exe编译器，由于MinGW头文件不符合MSVC语法规范，抛出C2059、C2143、C2085等大量编译错误，最终提示fast_tls依赖编译失败。
• 解压fast_tls源码包后通过Git Bash执行./configure && make命令：最初因未将用户.mix目录下的rebar加入环境变量，提示系统找不到指定文件；配置完rebar环境变量后，依旧触发cl.exe编译MinGW头文件的同类报错。

根因定位 #

排查确认问题核心：Windows环境下编译时，未正确拉取调用p1_utils、fast_tls依赖的pc v1.14.0 port_compiler端口编译工具，默认调用的cl.exe无法兼容GNU格式的编译参数与头文件，最终导致编译报错。

临时绕过方案 #

经测试可通过以下方式临时完成编译：

进入WSL子系统，切换到项目相同目录下执行mix compile，可成功生成.o、.d目标文件与正确的Erlang beam产物；此时返回Windows原生环境执行编译命令，可直接复用WSL生成的产物完成后续stun依赖安装。
注：原生Windows环境下直接编译始终无法正常执行，该方法仅为临时绕过方案。

正式修复 #

processone官方已针对该问题发布正式修复方案，可前往stun项目官方仓库的issue区查找对应问题公告获取修复指引。

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