预编译了一些工具的静态链接二进制，有需自取

[curoky]

最近又有用户报缺少 thriftc/protoc 或者版本用的不一样 。。。

主要有这么几个问题：

1. 因为共用物理机，用户不能直接 apt 安装
2. 即便申请 root 用 apt 安装了，debian 8/9 源里面的默认版本实在是太旧了。。。
3. 源码编译对用户来说成本太高了
4. 直接 copy 给用户编译好的二进制，又经常因为缺少 so 或者 glic 的版本太低无法运行

不久之前编译了一些静态链接的二进制，无任何系统库依赖(包括 glibc)，适用于任何 linux 发行版，最近正好拿出来给大家分享一下，本人是 clang-format/protoc/thriftc 重度用户，所以把这几个工具的每个核心版本都编译出来了，其它的工具如果大家有需求，可以提 issue 或者 pr ，有时间的话，可以一起支持了。

• github curoky/static-binaries
• download release

[waruqi]

@curoky 有的 可以试下 xmake

[ivyliner]

@curoky #12 求分享 all in homebrew 的解决方案, 我也被 C++ 的编译环境折腾不行不行的.

[Juszoe]

楼主写的这 1234 点完美戳中我的痛点，共用服务器说起来都是泪

[curoky]

@Nitroethane 你说的这个我明白，但生产真的有人（赶）这么搞吗😂，重新编译都能被 abi 问题搞得死死的，直接替换 so 那是真的艺高人胆大

[curoky]

@Nitroethane @lingxi27 可能开始确实说的有点绝对了，这个得拆开来看
1. 从工具角度来说，apt 引入动态链接二进制就是省了磁盘大小 /分发带宽，工具不存在极致性能考量。
2. 但是从服务角度，动态库确实提供了一些足够 solid 的属性，典型的像以 jemalloc 为代表的通过链接顺序 hook glibc 的符号的操作，确实很方便，但这不代表静态链接 jemalloc 达不到同样效果。
3. 个人觉得动态库这么猖狂的原因，还是因为 c/c++没有包管理工具，导致大型开源项目只能先根据 autotool/...独立编译为动态库，而后将动态库跟主项目捆绑，从而导致了万恶的预编译的诞生，最后美其名曰：提高了编译速度。

[curoky]

@ivyliner 我说的 all in homebrew 是指 MacOS/Linux 所有工具都 brew 安装，经过一年的努力，已经把 apt 安装的包都替换完了。但是 c++ 开发环境不适合用 homebrew 这种玩具了，还是 google 的 bazel 或者 fb 的 buck 比较靠谱，除编译器外，其它都很容易与系统库解绑，全链路源码编译+全链路静态链接，这块跟 golang 差不多了。

[curoky]

@waruqi 嗯嗯，听说过 xmake ，据说还不错，不过确实是没见几个基础库用过😂。之前玩过 autolools/make/cmake/vcpkg/conan/自研 /brew/blade/bazel ，听说最近 c++ 20 又有引入了 module ，也不知道以后还会有啥... 反正隔壁的 go mod 是真的香是真的...

[curoky]

@hsfzxjy 是个好东西，之前也有用过 patchelf 这类的工具，不过这相当于又增加了一个依赖项（或者说心智负担😂），折腾的多了现在喜欢纯粹、直接，所见即所得，拒绝黑盒😂

[flynaj]

共用物理机建议还是上 lxc.