不同版本的 Linux 用同一个二进制文件，有什么需要注意的地方？

[mytry]

打算把之前的在线代理做一个二进制的版本，不用每次安装都要编译和装一大堆依赖。刚刚试了下把 CentOS 编译的 nginx 二进制放到 Ubuntu 上可以运行，不知道会不会存在一些潜在的问题。

比如有些机器不支持某些 CPU 高级指令，是不是会出现问题？或者性能是不是自己编译的更高？

[junjieyuanxiling]

主要是依赖和 CPU 架构问题

[xiri]

完全静态编译、连接的话，只要 cpu 架构一样应该是没啥问题的，像 go 一样

[PTLin]

编译的时候没有高级特性应该没问题，动态链接的话要注意一下依赖问题，不然可能 segment fault。

[FrankHB]

ABI (e.g. libstdc++)
LD_LIBRARY_PATH/rpath
内核版本和兼容性 (e.g. ELF section .note.ABI-tag)
syscall 实现偷工减料的可能性 (e.g. WSL fakeroot)

[zanzhz1101]

所以 docker 多好

[mywaiting]

搞个交叉编译啊，这样就没事了~

[zanzhz1101]

静态编译就好了吧，基本也都是 x86

[KigKrazy]

docker 搞起···

[mytry]

@zanzhz1101 docker 不太熟~ 用了 docker 可以做到发布一次到处运行吗？ IO 性能方面是不是会有损失？

[zanzhz1101]

@mytry #9 他是相当于把服务的运行环境打成了一个包，docker 虚拟的是系统资源，io 的话我觉得问题应该不大，估计影响不会大于 5%，我觉得大佬你先考虑下静态编译，但是包会变大不少，然后再考虑 docker 化分支啥的，方便部署，x86 的二进制包基本没啥问题

[iwtbauh]

@xiri #2

静态链接的话会有内核问题。程序将会依赖最低内核版本。

[iwtbauh]

避免静态链接，一旦静态链接，就会造成很多严重的二进制可移植性问题。

例如内核依赖的问题。你静态链接的 libc 可能与当前系统其他部分有耦合，更换环境可能导致部分功能异常（例如域名解析相关）。

最严重的是静态链接的程序无法使用 dlopen 系列函数。对于某些程序可能是致命性的。

如果提高二进制可移植性？

1。不要用 -static
2。libc （如 glibc ）绝对不要静态链接
3。 静态链接 libgcc，libstdc++，libssl，libcrypto，libcurl 等，如果可以，后面几个尽量用自己编译的而不是发行版提供的版本。

[Reficul]

docker 也帮不了内核的坑😂🤣

[FrankHB]

@iwtbauh libc 不要静态链接这点强调得好，我给漏了。（因为没刻意往作大死方向上想。）
不过这个恐怕还是历史惯性的关系，按道理讲 C 都不提供的功能 libc 就不该多管，libc 本身并没有做系统调用中间层的义务，也不干 loader 什么事。Windows 上 libc/msvcrt 和 kernel32 之类的就是分开的（虽然算上 libc(mt)多版本坑一点都不小就是了）。

[azh7138m]

ovz 小鸡不能跑 docker 的（

[akira]

32/64 呀
还有 arm 要不要考虑

[jim9606]

如果要跨发行版兼容的话（客户程序分发）可以用一些容器化的打包方案，例如 Snap,Flatpak,非容器化的方案有 appimage,通用性相对差些。这些方案基本上都是用一些手段打包全部依赖。
服务器应用我觉得 docker 足够解决问题了，除非你要支持的平台用不了 docker(例如 openvz，用 2.6 旧内核的 RHEL/CentOS)

[jinliming2]

架构一样就没什么问题。
建议静态链接。
动态链接的话，建议跑起来用 lsof 看一下依赖，然后把所有依赖都拷贝到一个目录下，保持原有目录结构，然后用 chroot 运行。

[qinghon]

楼主是说的 nginx 的编译吗，我觉得直接参照 nginx 的官方 docker 镜像，改编译参数就可以了，这样同样可以做到，缺点就是 ovz