由于项目需要，我要基于 gRPC 开发一个通用的 wrapper ，前期已经将服务器侧相关的 gRPC 代码完成了集成，并基于 fake golang client 进行了功能测试，原以为生成 C/C++ gRPC 代码肯定是手到擒来的事情，没想到……居然“编译过程”本身成为了拦路虎。
按照 quickstart 文档的说明，可以使用的编译工具有如下三种
- cmake
- bazel（复杂，较高学习成本，且后续用不到）
- make（不推荐，人家说这个过时了）
既然如此，直接按照 cmake 的要求进行操作即可
# Choose a directory to hold locally installed packages.
$ export MY_INSTALL_DIR=$HOME/.local
$ mkdir -p $MY_INSTALL_DIR
$ export PATH="$MY_INSTALL_DIR/bin:$PATH"
# 安装高版本 cmake
$ wget -q -O cmake-linux.sh https://github.com/Kitware/CMake/releases/download/v3.19.6/cmake-3.19.6-Linux-x86_64.sh
$ sh cmake-linux.sh -- --skip-license --prefix=$MY_INSTALL_DIR
$ rm cmake-linux.sh
# Install the basic tools required to build gRPC
$ sudo apt install -y build-essential autoconf libtool pkg-config
结果……
0x01 困难一：公司网络环境下无法成功将相应内容下载到本地
这个命令其实隐含了很多外网下载内容，正常情况下很难下载完全，dddd
$ git clone --recurse-submodules -b v1.41.0 https://github.com/grpc/grpc
好在，我有国外 vps 可用，下载、打包，回传，一条龙解决问题
0x02 困难二：构建 c++gRPC 过程中对内存有相当高的要求
按照官方文档，只要执行如下命令，就可以得到需要的二进制程序了
# Build and install gRPC and Protocol Buffers
$ cd grpc
$ mkdir -p cmake/build
$ pushd cmake/build
$ cmake -DgRPC_INSTALL=ON \
-DgRPC_BUILD_TESTS=OFF \
-DCMAKE_INSTALL_PREFIX=$MY_INSTALL_DIR \
../..
$ make -j
$ make install
$ popd
然而，实际执行时，你会发现……一般的机器根本就无法正常执行完成上述命令。
NOTE: 下文给出的是，成功编译过程中内存使用情况的记录（之前失败了无数次，浪费了大量时间）
经过无数次的调整，最终在一台内存资源相对充足（可用内存 30G），并开了 55G 的 swap 的机器上，成功解决了编译过程对内存量的“变态”需求（内存不足，会导致编译过程直接挂掉）
![]()
![]()
![]()
![]()
![]()
结论：要想成功编译出来 C++ gRPC 相关的东西，对编译机有非常高的要求（注：这里是严格按照官方命令进执行的，可能存在调整了一些参数后，相应要求会变低的可能，但我没有去验证这个猜想）
最后，提供一张由于内存不足，编译过程中被强行杀掉的现场图
![]()
0x03 困难三：vbox 虚拟盘大小只增不减问题
这个问题准确来说，是在解决第二个问题时出现的“衍生”问题。
问题是这样的：我的开发环境是在 vbox 虚拟机中创建的，最初分给该虚拟机的内存只有 2G，当我通过 make -j 编译时，很容易就会因为内存不足而被系统杀死，于是我第一时间就想到了通过创建 swap 缓解内存不足问题的手段。在创建了一个 10G 的 swap 分区重新编译后发现，依然会出现内存不足情况，于是继续增加 swap 大小，一路从 10G 调整到了 50G ，之后发现新的问题产生了，这时不再报内存不足的错误，而是 vbox 虚拟机直接挂掉了~~
简单排查后发现，居然是因为 vbox 所属物理机上对应分区的磁盘空间不足了，此时我第一反应是“不应该啊”，之前明明还有50G 左右的空间呢呀~~我靠……难道是……
是的，没错，开了 swap 之后，随着编译的进行，随着虚拟机内部对“内存”的疯狂占用，间接导致了物理机上的磁盘空间被“真实”的用光了
然而，从上面的编译过程来看，编译结束之后，内存占用会被完全释放掉的，那么物理机上被占用的空间能否被释放掉么？
此时，需要补充两个关于 vbox 虚拟机的知识点：
第一，vbox 虚拟盘的设定大小和实际占用大小在最初并不是一致的，而是在实际使用后，按需逐渐增大的
例如，这个由 vbox 默认创建的虚拟盘，“虚拟分配空间”大小为10G，但“实际分配空间”大小为 1.31G
![]()
另外一个虚拟盘是我最初规划时就为虚拟机额外挂载的、最大可达 100G 的虚拟盘；当我创建了 50G 的 swap ，并开始编译 c++ gRPC 之后，由于系统内存不足，触发了对 swap 的使用，最终该盘的“实际分配空间”逐渐增大到了 54.59G
![]()
第二，vbox 虚拟盘的“实际分配空间大小”只能增加不能减少，这也就意味着，虽然我是为了编译 c++ gRPC 临时分配了 50G 的 swap ，并且事后在虚拟机内部将其完全删除，但在物理机上看，该空间依然存在，且会一直存在了……
针对 vdi 格式的虚拟盘，网上能够找到的“攻略”都是教你如何“增大”的
![]()
软件界面上确实也直接告之了“存储空间缩减的功能尚未实现”
![]()
尝试了下“增大”功能，确实可以
![]()
最后，还剩下一个问题，由于“只增不减”的缘故，vbox 虚拟盘已经将我的 xx 盘几乎撑爆 ，仅剩下可怜的几十M空间，这个问题也得解决，要不然影响后续使用
常规操作，“复制粘贴”大法走起，确实解决了磁盘空间问题，但搬移后发现，虚拟机启动直接报错，大致意思是“找不到盘了”，嗯，合理，毕竟被移动了
于是，将原来挂的盘片删掉
![]()
再将搬移到新位置的盘片挂上……结果，又报错了，错误类似下图（原图当时没截取）
![]()
大致意思是，新挂上去的虚拟盘的 UUID 和原来已经注册过的虚拟盘的 UUID 相同，不允许挂；
具体解决办法可以参考如下链接文章，这里就不赘述了：
-
https://www.vdiskrecovery.com/blog/fix-virtualbox-cannot-register-hard-disk/
-
https://www.wintips.org/fix-virtualbox-failed-to-open-hard-disk-file-cannot-register-virtual-hard-disk-because-a-disk-with-the-same-uuid-already-exists/
最后的最后，终于成功的挂上了盘，终于再次成功的启动了我的开发机……
![]()
OK， 到这里，我只是解决了编译环境问题，真正的 c++ gRPC 代码的开发调试，还没开始呢……
PS：本文敏感字如下，呵呵
![]()
更多精彩内容，欢迎关注我个人微信公众号
![]()
![]()
