你们手头上的 Linux 的 glibc 版本一般都是多少呢

2.17 的路过

不想把系统滚死的话，不要手痒折腾 glibc

跟着系统包走。系统包升就升，不升就不升。（这不是常识么……

# /lib/x86_64-linux-gnu/libc-2.27.so
GNU C Library (Debian GLIBC 2.27-6) stable release version 2.27.

看你什么系统，过旧的系统可以考虑自己升级，但如果是该发行版本较新的版本，那就没有必要。
比如 CentOS 7，glibc 2.17 完全足够了。大不了自己编译程序总可以吧。

@msg7086 我是 LFS 用户， 编译出来的系统用的就是 glibc-2.28

@aliipay @kn007 看来大部分都至少能保证 glibc-2.17 了， 不知道内核能不能保证 3.16 以上呢

@where2go LFS 那就跟着 LFS 的包走就行了嘛。
一般人还是发行版用得多，不会跟着潮流去滚包的。

gentoo 跟系统走的话，2.26

2.26

Arch 也是 2.28 ，然后编译出来的应用丢服务器上经常有 glibc 兼容问题，并不是很想用 docker 附带整系统，我现在用的是 patchelf 加一个 so 集合做兼容包（

手贱折腾过一次，后来再也不自己升级了

实在有指定版本的必要 用 docker 隔离多好

@codehz

分发二进制软件时，glibc 兼容问题，一般编译软件在一个相对旧的发行版上编译即可（如 Debian oldstable ）。

有源码为什么要在自己工作站上编译？应该直接在服务器上编译呀。

如果服务器不是你在管理，你可以试试分发 llvm IR

@iwtbauh #14 用了一些新编译器的独占特性（其实这都算好的了，没碰上 kernal is too old 就都可以强行 patchelf 解决

@codehz 不一定要附带整个系统的.可以看看 stretch 镜像.或者对 glibc 没有硬需求的话.可以考虑使用 musl-libc 的 alpine

@codehz 我也是这么干的
debian 编译，编译时就指定了 LDPATH，打包 so 分发
跨大版本跑没问题，甚至跨发行版跑也没问题

不过生产环境不敢这么干，都是不同大版本编译一份

@mmtromsb456 #16 刚想提这个呢，就是对 glibc 版本有强依赖，连 dlopen/dlsym 都解决不了，然后我实际上是 strace -e file 运行后，把所有读取的 so 文件拷贝过去了（所以也不是很大（

kernel: 4.19rc6
glibc: 2.28
xubuntu
(自己编译升级的

archlinux 2.28