这是一个创建于 1380 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近又有用户报缺少 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
 | 1 v2geek 2021-12-30 23:33:33 +08:00 为啥不用 docker ，直接用编译好的 |
 | 2 ETiV 2021-12-30 23:35:27 +08:00 via iPhone 和我一样，不过我原则就是喜欢 0 依赖的（也是被 CoreOS 逼的） build 过 htop 、tmux 、xtrabackup |
 | 3 curoky OP @v2geek 是说开发环境吗? 部署环境是 k8s ，但是开发环境是多租户的物理机，因为安全原因（ root 安装的 docker 很容易提权），没有给用户开 docker 权限，所以就很难受了... 因为用户特别多，每给用户增加一条工序，oncall 数量成指数增长 |
 | 4 wtl 2021-12-30 23:43:34 +08:00 nix 大法好 |
 | 6 Jooooooooo 2021-12-30 23:49:01 +08:00 c 为啥会这么复杂... |
| 7 curoky OP 而且线上部署打包的时候都是把所有 so 都 bundle 上（包括 glibc 这种系统库），加起来产物大小是静态链接的好几倍，反而导致上线特别慢，完全颠覆了设计预期了，想想就来气... |
 | 8 Buges 2021-12-30 23:49:25 +08:00 via Android @curoky 可以用 rootless mode 或开 uid 隔离，虽然有部分限制但仅仅是编译环境的话不会有什么问题。 |
 | 9 jim9606 2021-12-30 23:52:40 +08:00 其实只有 glibc 会恶心人，因为许可证不允许这玩意静态链接非 GPL/LGPL 程序。 musl 倒是没这问题，但很多项目没法用这个。 |
| 11 curoky OP @jim9606 国内公司谁管这些版权啥的啊 ，主要是 c++ 编译工具链做的一坨 X ，每次产物都 bundle 几十个 so 文件，每天能跑起来就谢天谢地了，之前遇到个动态库版本导致的 abi 问题，硬是 toubleshooting 了一个双月 |
| 12 curoky OP  1 @wtl 刚看了下描述，感觉是个好东西，不过前年开始就 all in homebrew 了，同样可以做到对系统库接近 0 依赖（主要还是 glibc 不容易做掉），而且它最大的好处是同时支持 Linux/MacOS ，而且 rootless 。 |
| 13 curoky OP 1 @Jooooooooo 趁年轻，还是早点转 go/rust 比较好，c/c++ 但凡有个靠谱的 modern build system ，也不至于到现在连个靠谱的 modern build system 都没有 |
 | 14 12101111 2021-12-31 00:11:02 +08:00 用 gentoo prefix 得了，只依赖 Linux 内核，最低支持到 CentOS6 内核，搞物理的都用这个 |
| 15 curoky OP @12101111 给 homebrew 开了两年光了，实在是折腾不动了，后面有精力再研究下老哥们提到的 nix/gentoo 大法，不过说到底还是一开始没踩对坑... |
| 16 Buges 2021-12-31 00:33:21 +08:00 via Android @jim9606 错了，glibc 不是许可证的问题，而是本身设计的就不是为了静态链接工作的。glibc 在运行时会通过 dlopen 获取自身的 handler ，如果静态链接 glibc 就会取得主程序 /系统中的另一个版本的 glibc 的 handler ，会产生什么结果那就谁也不知道了。另外 glibc 的 abi 稳定程度是完全可以作为系统接口使用，基本上不是太旧都没问题，或许不如 win32 的兼容性但至少不会差于 macos 。具体可以看看 linuxbrew 能够支持到的 glibc 版本。 @curoky rootless docker 不需要开权限，普通用户就能安装，当然要满足一些条件（内核允许 user_ns/专门的 overlayfs 驱动）。听说 podman 对 rootless 的支持更好一些。 |
 | 17 thedrwu 2021-12-31 01:35:19 +08:00 via Android tmux 开个对应系统的 docker 编译起新版本来还算快，但是忍了服务器上的 clangd/formatter 好久了，自己又懒得编译。 vim 这类有许多零散文件的估计只能自己编译到 home 目录。 |
 | 18 hsfzxjy 2021-12-31 01:43:48 +08:00 via Android |
 | 19 Nitroethane 2021-12-31 01:59:57 +08:00 via iPhone @curoky 共享库可不只是为了节省磁盘空间。 1. 假设某个项目用到的第三方库被爆出很严重的漏洞，此第三方库修复之后发布了补丁版本。动态链接情况：只需要更新共享库。静态链接情况：下载补丁版本，重新编译并发布自己的项目。 2. 节省内存。例如每个程序都用到的 libc 库，动态链接情况下只需要在内存中加载一份 lib 共享库。 |
 | 23 Juszoe 2021-12-31 09:43:41 +08:00 1 楼主写的这 1234 点完美戳中我的痛点，共用服务器说起来都是泪 |
| 24 curoky OP @Nitroethane 你说的这个我明白，但生产真的有人（赶）这么搞吗，重新编译都能被 abi 问题搞得死死的，直接替换 so 那是真的艺高人胆大 |
| 25 curoky OP @Nitroethane @lingxi27 可能开始确实说的有点绝对了，这个得拆开来看 1. 从工具角度来说，apt 引入动态链接二进制就是省了磁盘大小 /分发带宽，工具不存在极致性能考量。 2. 但是从服务角度，动态库确实提供了一些足够 solid 的属性，典型的像以 jemalloc 为代表的通过链接顺序 hook glibc 的符号的操作，确实很方便，但这不代表静态链接 jemalloc 达不到同样效果。 3. 个人觉得动态库这么猖狂的原因，还是因为 c/c++没有包管理工具，导致大型开源项目只能先根据 autotool/...独立编译为动态库，而后将动态库跟主项目捆绑，从而导致了万恶的预编译的诞生，最后美其名曰：提高了编译速度。 |
| &nbp; 26 curoky OP @ivyliner 我说的 all in homebrew 是指 MacOS/Linux 所有工具都 brew 安装，经过一年的努力，已经把 apt 安装的包都替换完了。但是 c++ 开发环境不适合用 homebrew 这种玩具了，还是 google 的 bazel 或者 fb 的 buck 比较靠谱，除编译器外，其它都很容易与系统库解绑，全链路源码编译+全链路静态链接，这块跟 golang 差不多了。 |
| 27 curoky OP @waruqi 嗯嗯，听说过 xmake ，据说还不错，不过确实是没见几个基础库用过。之前玩过 autolools/make/cmake/vcpkg/conan/自研 /brew/blade/bazel ，听说最近 c++ 20 又有引入了 module ，也不知道以后还会有啥... 反正隔壁的 go mod 是真的香是真的... |
| 28 curoky OP @hsfzxjy 是个好东西，之前也有用过 patchelf 这类的工具，不过这相当于又增加了一个依赖项（或者说心智负担），折腾的多了现在喜欢纯粹、直接，所见即所得，拒绝黑盒 |
 | 29 flynaj 2022-01-02 01:53:38 +08:00 via Android 共用物理机建议还是上 lxc. |
Select Language