Linux下分发仅二进制软件时不应包含哪些共享库？

在Linux分发应用（尤其是游戏）时，用发行版包管理器虽能复用系统已有的稳定库，但存在多发行版适配成本高、小众发行版用户需自行配置依赖的问题；部分平台（如itch.io）还会忽略.deb/.rpm包，因此常采用「基于旧系统构建+复制依赖库」的分发方式。针对你提出的核心疑问，逐一解答如下：

是否必须附带libc？ #

不是必须，但不附带的话兼容性风险高，附带则容易引发冲突。

libc是Linux系统最核心的基础库，不同发行版的libc版本差异会直接导致程序崩溃。如果你的程序基于Debian oldstable或Steam Runtime这类旧系统编译，新版系统的libc理论上能兼容旧编译产物，但一旦遇到libc的ABI变更（比如glibc某些版本的符号改动），程序仍可能无法启动。

如果强行附带libc，大概率会和系统自带的libc发生冲突——动态链接器可能混合加载不同版本的libc，直接引发崩溃。因此常规做法是不附带系统级libc，靠旧编译环境来保证对新版libc的兼容性；或者选择静态编译libc，但静态编译会导致动态链接的NSS模块（如DNS解析、用户认证）无法正常工作，仅适合特定场景。

新版libc是否保证与旧版向下兼容？ #

主流libc（如glibc）仅提供有限的向下兼容：新版libc可以运行针对旧版编译的程序，但反过来（旧libc运行新版编译的程序）完全不行。

但这个兼容不是绝对的：比如glibc的某些私有符号在新版本中可能被移除，如果你编译时依赖了这些符号，新版系统上程序会报错；另外，musl libc和glibc之间完全不兼容——针对glibc编译的程序，在Alpine这类musl系统上即使有新版musl也无法运行。

能否为求稳妥附带所有依赖？此举是否能在多数系统运行？ #

直接打包所有依赖看似稳妥，实际会踩大量坑，几乎不可能在多数系统正常运行：

• 库冲突问题：比如你打包了自己的libc，动态链接器可能同时加载系统和你打包的libc，导致程序直接崩溃；
• 系统环境绑定问题：像libX11、libGL这类和桌面环境、显卡驱动绑定的库，你打包的旧版本可能和用户的系统组件不兼容，出现显示异常、无法启动窗口等问题；
• 系统服务依赖问题：libpam、libsystemd这类和系统认证、服务管理绑定的库，打包版本根本无法适配用户系统的配置，直接失效。

因此打包所有依赖是不可行的，反而会引入更多兼容性故障。

应包含和排除哪些共享库？ #

建议包含的库 #

• 应用专属的第三方库：比如游戏引擎的自定义库、特定版本的SDL、GLFW、OpenAL这类非系统基础库——这些库在不同发行版中版本差异大，用户系统可能没有或版本不兼容；
• 特定版本的通用库：如果你的程序依赖了某款通用库的新特性，而旧系统默认没有（比如特定版本的libpng），可以打包和你编译环境匹配的旧版本库。

必须排除的库 #

• 系统核心基础库：libc.so.6、libm.so.6、libdl.so.2、librt.so.1这类glibc核心组件，绝对不能打包，否则必然引发系统库冲突；
• 与系统环境强绑定的库：
  • 图形类：libX11.so.6、libGL.so.1、libEGL.so.1（依赖用户的显卡驱动和桌面环境，打包旧版本会导致渲染异常）；
  • 系统服务类：libpam.so.0、libsystemd.so.0（和系统认证、服务管理绑定，无法适配用户系统）；
  • 动态链接器：ld-linux-x86-64.so.2（系统级组件，强制使用自定义版本会导致程序加载失败）。

内容的提问来源于stack exchange，提问作者xiver77