C++动态库向前兼容的能力，真是一言难尽。

[tool2d]

公司有个运行在外网的生产环境，是 linux 早期版本，本着只要代码能运行，就没人去动的原则，内核一直比较老。

然后我想加一点小功能，想着现在 clang 那么强大了，跨平台编译应该轻轻松松，然而测试结果让我大跌眼镜。

目前几乎所有的 clang 交叉编译环境，都是基于新版本的 GLIBC ，相当于 VC 的 Runtime Lib ，而这货竟然严重依赖于系统内核版本？测试了好几个打包编译器，都是顺利生成 ELF ，可运行报错，提示让先升级内核。

无奈，一点点换老款编译器，从 2022 年的 clang ，到 2020 年的 clang ，到 2012 年的 gcc, 再到 2007 年的 gcc ，最后一个终于运行成功！

硬着头皮，用最原始的编译器，写最炫酷的 2023 新代码。

[ipwx]

@icylogic glibc 有点像 windows 的 kernelXX.dll ，封装了很多 syscall 相关的东西。

然后有一种 docker 镜像叫做 manylinux 镜像，目的就是为可移植的 二进制编译 提供帮助。

https://github.com/pypa/manylinux

虽然主要用于 python 社区的二进制分发，但 python 你懂的，一堆 C/C++ 扩展，所以 C++ 的工具链是齐的。

[urnoob]

@uiosun
没听过 java 还有这么一说 从来都是 跨平台 还是回到讨论 cpp 上吧

[Zepp]

https://stackoverflow.com/a/11207190
看看这个？ gcc 有选项可以指定兼容的内核版本的

[Zepp]

@Zepp #43 sorry 我好像搞错了，这里说的是编译 glibc 时的 configure 选项，需要你自己重编译 glibc 才行

[tool2d]

@Zepp 嗯，我也看到了。查过的几个别人编译好的 gcc/clang 参数，基本都是默认值，没人去主动修改。

也许自己编译 GLIBC 是可行的，只是我没有尝试。

还有一点我帖子里没提到，实验下来编译 i386 ELF 是不限制内核版本的，只有 x64 位的 ELF 才限制。

[jones2000]

项目所有代码在目标机器上源码编译，不就可以了。 除非有些库你没有重新编译

[luoqeng]

还能 golang 有远见，绕过 glibc ，直接 syscall

[nmap]

这种场景就是 golang 最大的优势之一

[codehz]

zig 内建的 clang 可以随意指定 glibc 的版本，就当作 abi 三元组的一部分
-target x86_64-linux-gnu.2.34 就能链接到 glibc 2.34 的版本（其他版本以此类推，最低到 2.16 ，十年前的版本），而且不在乎编译平台的 glibc 版本，甚至 windows 上也可以生成 linux 的 binary
参考 https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html

[learningman]

@luoqeng 然后 cgo 又回去了

[jinsongzhao]

@nmap golang 一样，你试试最新版本去低版本操作系统跑一下试试，还是得换最老版本的 go 编译

[jinsongzhao]

@luvroot golang 的静态编译一样

[jinsongzhao]

golang 自带了很多库，所以好很多而已，但是本质一样，依赖操作系统本身的向下兼容