直接运行 /lib/libc.so.6 就能看到版本号
都升级到 glibc 2.28 了么
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Linux_compatibility_matrix

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 完全足够了。大不了自己编译程序总可以吧。

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

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

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

gentoo 跟系统走的话，2.26

2.26

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

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

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


分发二进制软件时，glibc 兼容问题，一般编译软件在一个相对旧的发行版上编译即可（如 Debian oldstable ）。
有源码为什么要在自己工作站上编译？应该直接在服务器上编译呀。
如果服务器不是你在管理，你可以试试分发 llvm IR

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

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

我也是这么干的
debian 编译，编译时就指定了 LDPATH，打包 so 分发
跨大版本跑没问题，甚至跨发行版跑也没问题
不过生产环境不敢这么干，都是不同大版本编译一份

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

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

archlinux 2.28

比较好奇，为什么 Debian 8 的内核版本比 Debian 7 的还低一点，刚开了虚拟机看了一下，我的 Debian 8 已经升级到最新的 8.11 版本，内核确实还是 3.16 版。


怎么看出 2 > 16 的

哈哈，我错了～ 妹想到 minor 会迭代这么多版本。。。
https://en.wikipedia.org/wiki/List_of_Linux_kernel_names

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

他山万年历，兼容 libc 2.5+ 32/64 linux 任意图形桌面系统