最近又有用户报缺少 thriftc/protoc 或者版本用的不一样 。。。
主要有这么几个问题：

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

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

github curoky/static-binaries
download release

为啥不用 docker ，直接用编译好的

和我一样，不过我原则就是喜欢 0 依赖的（也是被 CoreOS 逼的😂）

build 过 htop 、tmux 、xtrabackup

是说开发环境吗? 部署环境是 k8s ，但是开发环境是多租户的物理机，因为安全原因（ root 安装的 docker 很容易提权），没有给用户开 docker 权限，所以就很难受了... 因为用户特别多，每给用户增加一条工序，oncall 数量成指数增长🙈

nix 大法好

还不是因为上古时期为了节省磁盘空间嘛，搞动态库这种恶心死人的东西，现在谁缺这点磁盘空间... 🙈

c 为啥会这么复杂...

而且线上部署打包的时候都是把所有 so 都 bundle 上（包括 glibc 这种系统库），加起来产物大小是静态链接的好几倍，反而导致上线特别慢，完全颠覆了设计预期了，想想就来气...

可以用 rootless mode 或开 uid 隔离，虽然有部分限制但仅仅是编译环境的话不会有什么问题。

其实只有 glibc 会恶心人，因为许可证不允许这玩意静态链接非 GPL/LGPL 程序。
musl 倒是没这问题，但很多项目没法用这个。

😮‍💨，给大佬们反馈过，没采纳，想来是有很多坑吧，或者懒得折腾了。

国内公司谁管这些版权啥的啊 😂，主要是 c++ 编译工具链做的一坨 X ，每次产物都 bundle 几十个 so 文件，每天能跑起来就谢天谢地了，之前遇到个动态库版本导致的 abi 问题，硬是 toubleshooting 了一个双月 💔

刚看了下描述，感觉是个好东西，不过前年开始就 all in homebrew 了，同样可以做到对系统库接近 0 依赖（主要还是 glibc 不容易做掉），而且它最大的好处是同时支持 Linux/MacOS ，而且 rootless 。

趁年轻，还是早点转 go/rust 比较好，c/c++ 但凡有个靠谱的 modern build system ，也不至于到现在连个靠谱的 modern build system 都没有

用 gentoo prefix 得了，只依赖 Linux 内核，最低支持到 CentOS6 内核，搞物理的都用这个

给 homebrew 开了两年光了，实在是折腾不动了，后面有精力再研究下老哥们提到的 nix/gentoo 大法，不过说到底还是一开始没踩对坑...

错了，glibc 不是许可证的问题，而是本身设计的就不是为了静态链接工作的。glibc 在运行时会通过 dlopen 获取自身的 handler ，如果静态链接 glibc 就会取得主程序 /系统中的另一个版本的 glibc 的 handler ，会产生什么结果那就谁也不知道了。另外 glibc 的 abi 稳定程度是完全可以作为系统接口使用，基本上不是太旧都没问题，或许不如 win32 的兼容性但至少不会差于 macos 。具体可以看看 linuxbrew 能够支持到的 glibc 版本。
rootless docker 不需要开权限，普通用户就能安装，当然要满足一些条件（内核允许 user_ns/专门的 overlayfs 驱动）。听说 podman 对 rootless 的支持更好一些。

tmux 开个对应系统的 docker 编译起新版本来还算快，但是忍了服务器上的 clangd/formatter 好久了，自己又懒得编译。

vim 这类有许多零散文件的估计只能自己编译到 home 目录。

github.com/intoli/exodus 试试这个

共享库可不只是为了节省磁盘空间。

1. 假设某个项目用到的第三方库被爆出很严重的漏洞，此第三方库修复之后发布了补丁版本。动态链接情况：只需要更新共享库。静态链接情况：下载补丁版本，重新编译并发布自己的项目。

2. 节省内存。例如每个程序都用到的 libc 库，动态链接情况下只需要在内存中加载一份 libc 共享库。

   动态链接可不仅仅是节约空间那么简单，debug 静态链接的顺序问题也是很恶心的

   有的 可以试下 xmake

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

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

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

可能开始确实说的有点绝对了，这个得拆开来看

1. 从工具角度来说，apt 引入动态链接二进制就是省了磁盘大小 /分发带宽，工具不存在极致性能考量。
2. 但是从服务角度，动态库确实提供了一些足够 solid 的属性，典型的像以 jemalloc 为代表的通过链接顺序 hook glibc 的符号的操作，确实很方便，但这不代表静态链接 jemalloc 达不到同样效果。

3. 个人觉得动态库这么猖狂的原因，还是因为 c/c++没有包管理工具，导致大型开源项目只能先根据 autotool/...独立编译为动态库，而后将动态库跟主项目捆绑，从而导致了万恶的预编译的诞生，最后美其名曰：提高了编译速度。

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

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

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