7
预编译了一些工具的静态链接二进制，有需自取
source link: https://www.v2ex.com/t/825390
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
最近又有用户报缺少 thriftc/protoc 或者版本用的不一样 。。。
主要有这么几个问题：
- 因为共用物理机，用户不能直接 apt 安装
- 即便申请 root 用 apt 安装了，debian 8/9 源里面的默认版本实在是太旧了。。。
- 源码编译对用户来说成本太高了
- 直接 copy 给用户编译好的二进制，又经常因为缺少 so 或者 glic 的版本太低无法运行
不久之前编译了一些静态链接的二进制，无任何系统库依赖(包括 glibc)，适用于任何 linux 发行版，最近正好拿出来给大家分享一下，本人是 clang-format/protoc/thriftc 重度用户，所以把这几个工具的每个核心版本都编译出来了，其它的工具如果大家有需求，可以提 issue 或者 pr ，有时间的话，可以一起支持了。
28 条回复 • 2021-12-31 11:22:11 +08:00
curoky 23 小时 22 分钟前
@v2geek 是说开发环境吗? 部署环境是 k8s ，但是开发环境是多租户的物理机，因为安全原因（ root 安装的 docker 很容易提权），没有给用户开 docker 权限，所以就很难受了... 因为用户特别多，每给用户增加一条工序，oncall 数量成指数增长🙈
curoky 23 小时 15 分钟前
而且线上部署打包的时候都是把所有 so 都 bundle 上（包括 glibc 这种系统库），加起来产物大小是静态链接的好几倍，反而导致上线特别慢，完全颠覆了设计预期了，想想就来气...
curoky 23 小时 4 分钟前
@jim9606 国内公司谁管这些版权啥的啊 😂，主要是 c++ 编译工具链做的一坨 X ，每次产物都 bundle 几十个 so 文件，每天能跑起来就谢天谢地了，之前遇到个动态库版本导致的 abi 问题，硬是 toubleshooting 了一个双月 💔
curoky 22 小时 58 分钟前 
1
@wtl 刚看了下描述，感觉是个好东西，不过前年开始就 all in homebrew 了，同样可以做到对系统库接近 0 依赖（主要还是 glibc 不容易做掉），而且它最大的好处是同时支持 Linux/MacOS ，而且 rootless 。
curoky 22 小时 56 分钟前 1
@Jooooooooo 趁年轻，还是早点转 go/rust 比较好，c/c++ 但凡有个靠谱的 modern build system ，也不至于到现在连个靠谱的 modern build system 都没有
curoky 22 小时 42 分钟前
@12101111 给 homebrew 开了两年光了，实在是折腾不动了，后面有精力再研究下老哥们提到的 nix/gentoo 大法，不过说到底还是一开始没踩对坑...
Buges 22 小时 30 分钟前 via Android
@jim9606 错了，glibc 不是许可证的问题，而是本身设计的就不是为了静态链接工作的。glibc 在运行时会通过 dlopen 获取自身的 handler ，如果静态链接 glibc 就会取得主程序 /系统中的另一个版本的 glibc 的 handler ，会产生什么结果那就谁也不知道了。另外 glibc 的 abi 稳定程度是完全可以作为系统接口使用，基本上不是太旧都没问题，或许不如 win32 的兼容性但至少不会差于 macos 。具体可以看看 linuxbrew 能够支持到的 glibc 版本。
@curoky rootless docker 不需要开权限，普通用户就能安装，当然要满足一些条件（内核允许 user_ns/专门的 overlayfs 驱动）。听说 podman 对 rootless 的支持更好一些。
@curoky rootless docker 不需要开权限，普通用户就能安装，当然要满足一些条件（内核允许 user_ns/专门的 overlayfs 驱动）。听说 podman 对 rootless 的支持更好一些。
thedrwu 21 小时 28 分钟前 via Android
tmux 开个对应系统的 docker 编译起新版本来还算快，但是忍了服务器上的 clangd/formatter 好久了，自己又懒得编译。
vim 这类有许多零散文件的估计只能自己编译到 home 目录。
vim 这类有许多零散文件的估计只能自己编译到 home 目录。
Nitroethane 21 小时 4 分钟前 via iPhone
@curoky 共享库可不只是为了节省磁盘空间。
1. 假设某个项目用到的第三方库被爆出很严重的漏洞，此第三方库修复之后发布了补丁版本。动态链接情况：只需要更新共享库。静态链接情况：下载补丁版本，重新编译并发布自己的项目。
2. 节省内存。例如每个程序都用到的 libc 库，动态链接情况下只需要在内存中加载一份 libc 共享库。
1. 假设某个项目用到的第三方库被爆出很严重的漏洞，此第三方库修复之后发布了补丁版本。动态链接情况：只需要更新共享库。静态链接情况：下载补丁版本，重新编译并发布自己的项目。
2. 节省内存。例如每个程序都用到的 libc 库，动态链接情况下只需要在内存中加载一份 libc 共享库。
curoky 12 小时 56 分钟前 via Android
@Nitroethane 你说的这个我明白，但生产真的有人（赶）这么搞吗😂，重新编译都能被 abi 问题搞得死死的，直接替换 so 那是真的艺高人胆大
curoky 12 小时 27 分钟前 via Android
@Nitroethane @lingxi27 可能开始确实说的有点绝对了，这个得拆开来看
1. 从工具角度来说，apt 引入动态链接二进制就是省了磁盘大小 /分发带宽，工具不存在极致性能考量。
2. 但是从服务角度，动态库确实提供了一些足够 solid 的属性，典型的像以 jemalloc 为代表的通过链接顺序 hook glibc 的符号的操作，确实很方便，但这不代表静态链接 jemalloc 达不到同样效果。
3. 个人觉得动态库这么猖狂的原因，还是因为 c/c++没有包管理工具，导致大型开源项目只能先根据 autotool/...独立编译为动态库，而后将动态库跟主项目捆绑，从而导致了万恶的预编译的诞生，最后美其名曰：提高了编译速度。
1. 从工具角度来说，apt 引入动态链接二进制就是省了磁盘大小 /分发带宽，工具不存在极致性能考量。
2. 但是从服务角度，动态库确实提供了一些足够 solid 的属性，典型的像以 jemalloc 为代表的通过链接顺序 hook glibc 的符号的操作，确实很方便，但这不代表静态链接 jemalloc 达不到同样效果。
3. 个人觉得动态库这么猖狂的原因，还是因为 c/c++没有包管理工具，导致大型开源项目只能先根据 autotool/...独立编译为动态库，而后将动态库跟主项目捆绑，从而导致了万恶的预编译的诞生，最后美其名曰：提高了编译速度。
@ivyliner 我说的 all in homebrew 是指 MacOS/Linux 所有工具都 brew 安装，经过一年的努力，已经把 apt 安装的包都替换完了。但是 c++ 开发环境不适合用 homebrew 这种玩具了，还是 google 的 bazel 或者 fb 的 buck 比较靠谱，除编译器外，其它都很容易与系统库解绑，全链路源码编译+全链路静态链接，这块跟 golang 差不多了。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK