Windows 上为 uSockets 搭建开发环境

前言

前两天为 uWebSockets 增加了服务端的 unix domain socket 支持，联系了作者是否愿意接受我的 PR，得到的回复是需要能够跨平台并且客户端也需要支持。于是打算尝试在 Windows 上跑起来这个项目，然后在其上增加 unix domain socket 支持。搭建环境的过程很艰辛，花了我整整一天多的时间，C/C++ 开发还是在 Linux 下比较舒服。。。

过程

AF_UNIX && Windows SDK

Windows 后来支持了unix domain socket，需要下来安装 SDK 才能体验这项特性，具体可以看这篇博客，最新的 SDK 要 3 个 G，在网上搜了以前的版本，1 个 G 多点，这样也不用下太久。安装完之后就可以找到 afunix.h 头文件了。具体的 example 在微软的另一篇博客里。

vcpkg

C/C++ 免不了要依赖第三方库，如果每一项依赖都得由自己手动编译安装就很繁琐了。vcpkg 是一个跨平台的包管理工具，安装步骤在这里。我在安装完之后下载 libuv 的过程中遇到这个错误：Error: in triplet x64-windows: Unable to find a valid Visual Studio instance，一番 Google 之后解决了，需要在为 Visual Studio 安装 English language 以及安装一个组件：C++ CMake tools for Windows。具体看这里。

工具链

VS 的工具链和 GNU 的不同，GNU 的 g++ 和 gcc 在 VS 中都是 cl，命令格式也不一样，比如 g++ 中指定 include 目录是 -Ipath，cl 中是 /Ipath，-std=c17 在 cl 中是 /std:c17。。。一开始不知道这些差异，总是在 cl 中习惯性地写上 g++ 的命令格式导致出现了很多莫名其妙的问题。

make 运行 uSockets 中的 Makefile 时还报错找不到 CC，后来看了 Makefile 后知道 CC 是里面定义的一个变量，代指编译器。解决方法是在 make 命令中显示指明 CC：make CC=gcc.exe，但是这样编译出来的是一个个 .o 文件(linux 下的文件格式，Windows 中对应的是 .obj)，并且还报错找不到 uv.h，后来灵光一现把命令换成 make CC=cl.exe 就编译出 .obj 了，由于 Makefile 中没有为 Windows 定义把 .obj 打包成静态链接库的命令，所以我手动把编译出来的 .obj 打包成一个 .lib 了，步骤参考这篇博客。这里还有一个坑，VS 中有 link.exe，Git 中也有，而且在我的环境变量设置中 Git 的路径是靠前的，结果执行 link 的时候报错 /usr/bin/link: extra operand，接着在命令行中显示指定 VS 的 link 路径后执行打包命令就成功了，得知原因后把 Git 的路径挪到 VS 后面，这样每次执行 link 的时候就不用显示指定路径了。

环境变量的设置

编译的过程总是遇到找不到头文件以及运行时找不到动态链接的问题，猜想应该是环境变量的问题，参考了这篇博客，设置了一系列环境变量之后就 OK 了。下面是我的环境变量设置：

头文件：INCLUDE

1
2
3
4
E:\WindowsSDK\Lib\10.0.20344.0\um\x64
E:\WindowsSDK\Lib\10.0.20344.0\ucrt\x64
D:\developmentTools\VisualStudio2022\VC\Tools\MSVC\14.31.31103\lib\x64
D:\environment\vcpkg\installed\x64-windows\lib

静态链接库文：LIB

1
2
3
4
E:\WindowsSDK\Lib\10.0.20344.0\um\x64
E:\WindowsSDK\Lib\10.0.20344.0\ucrt\x64
D:\developmentTools\VisualStudio2022\VC\Tools\MSVC\14.31.31103\lib\x64
D:\environment\vcpkg\installed\x64-windows\lib

动态链接库：在 Path 中新增 vcpkg 存放 .dll 的路径
D:\environment\vcpkg\installed\x64-windows\bin

机器体系结构不匹配

在 CLion 中运行的时候总是报错“模块计算机类型“x64”与目标计算机类型“X86”的错误，我的机器是 x64 的，这实在让人迷惑，我设置在 CMake 中设置了一系列指令指定机器类型和编译器以及链接器的路径，结果还是得到一样或者反过来的错误。。。

1
2
3
4
5
6
7
set(CMAKE_EXE_LINKER_FLAGS "/machine:x64")

set(CMAKE_C_COMPILER "D:/developmentTools/VisualStudio2022/VC/Tools/MSVC/14.31.31103/bin/Hostx64/x64/cl.exe")
set(CMAKE_CXX_COMPILER "D:/developmentTools/VisualStudio2022/VC/Tools/MSVC/14.31.31103/bin/Hostx64/x64/cl.exe")
set(CMAKE_RC_COMPILER "E:/WindowsSDK/bin/10.0.20344.0/x64/rc.exe")
set(CMAKE_MT_COMPILER "E:/WindowsSDK/bin/10.0.20344.0/x64/mt.exe")
SET(CMAKE_C_LINK_EXECUTABLE "D:/developmentTools/VisualStudio2022/VC/Tools/MSVC/14.31.31103/bin/Hostx64/x64/link.exe")

后面想着去看看 CLion 中 toolchain 的设置，结果发现是 VS 的 Architecture 默认是 x86，换成 amd64 后就可以了。

总结

这个过程可谓是一波 N 折。。。不过最后成功在 CLion 中跑起来的时候心情还是很激动的。。。至于宇宙最强的 Visual Studio，我是真的不会用。。。。。。

参考

技术
C++ 环境搭建 GSoC

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！