了解二进制兼容性以及它与运行在 Linux® on POWER™ 上的不同操作环境之间的关系。考察 IBM 支持的两个 Linux on POWER 发行版，即 Red Hat Enterprise Linux (RHEL) 和 SUSE LINUX Enterprise Server (SLES)，了解它们各自的各个版本之间的二进制兼容性。总体而言，通过在版本之间维护的稳定 Application Binary Interface (ABI) 可以实现从基于 2.6.9 内核的 RHEL4 顺利迁移到基于 2.6.18 内核的 RHEL5。该方法同样适用于从基于 2.6.5 内核的 SLES9 迁移到基于 2.6.16 内核的 SLES10。了解能够改善 Linux on POWER 应用程序的性能的新技术，并遵循一些步骤确保未来的多个发行版之间的二进制兼容性。[“参考资料” 部分提供额外的参考内容 —— 编辑。]
现在有许多可用的 Linux 发行版。尽管 Red Hat 和 SUSE LINUX 是 IBM 支持的 Linux on POWER 解决方案供应商，但其他发行版（比如 Gentoo、Debian 和 Ubuntu）也逐渐变成流行的 Linux on POWER 解决方案。应用程序通常喜欢确保他们的应用程序能够运行在多个发行版上，以及运行在同一个发行版的不同版本上。理解与二进制兼容性相关的问题之后，就能够 实现这些目标。本文定义二进制兼容性、讨论维护兼容性的考虑事项并探讨不同版本之间的迁移，包括 Red Hat Enterprise Linux 的版本 4 和 5，SUSE LINUX Enterprise Server 的版本 9 和 10。此外，还提供确保应用程序能够跨多个发行版实现兼容性的实践。
表 1 显示了软件级别，以及本文将要详细讨论的 RHEL4、RHEL5、SLES9 和 SLES10 中受支持的特性：
表 1. 受支持的特性以及 RHEL 和 SLES 发行版的代码级别
| SLES8 SP4 | RHEL3 U4 | SLES9 SP3 | RHEL4 U8 | SLES10 SP2 | RHEL5 U3 | |
|---|---|---|---|---|---|---|
| kernel | 2.4.21 | 2.4.21 | 2.6.5 | 2.6.9 | 2.6.16 | 2.6.18 |
| glibc | 2.2.5 | 2.3.2 | 2.3.3 | 2.3.4 | 2.4 | 2.5 |
| SMT | No | No | Yes | Yes | Yes | Yes |
| NPTL | No | No | Yes | Yes | Yes | Yes |
| NUMA | No | No | Yes | Yes | Yes | Yes |
| JDK | IBM 1.3.1 | IBM 1.4.2¹ | IBM 1.4.2 | IBM 1.4.2 | IBM 1.4.2, 5.0 | IBM 1.4.2, 5.0 |
| Apache | 1.3.26 | 2.0.46 | 2.0.49 | 2.0.52 | 2.2.0 | 2.2.3 |
| GCC | 3.2 | 3.2.3 | 3.3.3 | 3.4.6 | 4.1.2 | 4.1.2 |
¹您可以从 IBM 站点下载 IBM Developer Kit for Linux, Java™ Technology Edition。（参考资料 部分提供相关链接）。
使用图 1 中显示的流程图确定应用程序在 RHEL 或 SLES 上是否实现二进制兼容。
图 1. 确定应用程序的二进制兼容性
  |
二进制兼容性概述
Linux on POWER 的二进制兼容性通过遵循 Application Binary Interface (ABI) 来实现。ABI 是一个接口，编译后的二进制文件通过它访问操作系统及其服务。当多个操作环境支持相同的 ABI 时，就可以在这些操作环境中运行相同的二进制文件。可以在 “64-bit PowerPC ELF Application Binary Interface Supplement 1.7” 中找到关于 PowerPC® Executable 和 Linking Format (ELF) ABI 的 64 位补充的更多信息（参考资料 部分提供相关链接）。
二进制兼容性是指能够在特定处理器系列的多个环境中运行二进制文件的能力。这些环境可能是相同 Linux 发行版的不同版本，或者是完全不同的版本。例如，在基于 POWER6™ 处理器并运行 SLES10 的系统上运行可以在基于 POWER5™ 处理器并运行 SLES10 的系统上编译和运行的二进制文件。另一个例子是，在基于 POWER6™ 处理器并运行 SLES10 的系统上运行可以在基于 POWER5™ 处理器并运行 RHEL4 的系统上编译和运行的二进制文件。
|
处理器兼容性
处理器兼容性是与 Linux on POWER 二进制兼容性密切相关的主题。这个小节讨论在不同的 64 位 POWER 处理器之间的兼容性，以及 32 位 PowerPC 处理器和 64 位 POWER 处理器之间的兼容性。
POWER 处理器兼容性
“二进制兼容性概述” 小节讨论的最后一个例子涉及到在两个不同的处理器类型上运行相同的二进制文件：POWER5 处理器和 POWER6 处理器。POWER6 架构是 POWER5 架构的改进，同时又保持与 POWER5 兼容，这就允许您在这两个平台上运行相同的应用程序。
PowerPC 和 POWER 处理器兼容性
运行在本机 32 位 PowerPC 环境和 64 位 POWER 环境上的 32 位应用程序也可以实现二进制兼容性。可以在本机 Linux PowerPC 环境上执行在 64 位 Linux on POWER 系统上生成的 32 位二进制文件。能够实现这种兼容性是因为：
- 64 位 Power Architecture 支持完整的 32 位 PowerPC 架构。
- 64 位 Linux 内核能够处理 32 位系统调用。
- 32 位运行时环境包含必要的 32 位库。
- 64 位运行时环境包含必要的 32 位和 64 位库。
可以通过不同的方式生成 32 位和 64 位 Linux 二进制文件，这取决于开发平台：
- 在 32 位 PowerPC 平台（比如运行 Linux 的 Apple Powerbook）上的本机 GNU Compiler Collection (GCC) C 编辑器能够生成可以在本机 32 位平台上，或在包含适当 32 位用户空间库的 64 位 Linux on POWER 平台上执行的 32 位二进制文件。
- IBM XL C/C++, Version 8.0 和针对 64 位 Linux on POWER 的 GCC C 编译器能够生成 32 位和 64 为二进制可执行文件，这些文件可以在 32 位或 64 位运行时环境中执行。
- 还 存在可以同时在 32 位 PowerPC Linux 系统和 64 位 Linux on POWER 系统上运行的跨系统编译器。这些跨系统编译器能够生成 32 位和 64 位二进制文件。不管在什么地方构建二进制文件，32 位的二进制文件都可以在 32 位 Linux 平台或 64 位 Linux 平台上运行，而生成的 64 位二进制文件仅能在 64 位 Linux on POWER 系统上运行。跨系统编译器的一个例子是 Crosstool（参考资料 部分提供相关链接）。
表 2 显示了如何为不同的开发平台生成 32 位和 64 位 Linux 二进制文件：
表 2. 生成 32 位和 64 位 Linux 二进制文件
| 开发平台 | 编译器 | 生成的 Linux 二进制文件 |
|---|---|---|
| 32 位 Linux on PowerPC | 本机 GCC C 编译器 | 32 位 |
| 64 位 Linux on POWER | 本机 XL C/C++ 或 GCC C 编译器 | 32 位或 64 位 |
| 32 位 Linux on PowerPC 或 64 位 Linux on POWER |
跨系统编译器，比如 crosstool | 32 位或 64 位 |
尽管已经演示了 32 位和 64 位环境之间的兼容性，但这并不意味着官方发行版支持这种兼容性。Red Hat 在 RHEL3 和 RHEL4 之间向前或向后支持 32 位和 64 位兼容性，而当从 SLES8 迁移到 SLES9 时，SLES8 仅支持 32 位向前兼容性。
表 3 显示了 32 位和 64 位应用程序在不同的 RHEL 和 SLES 版本上的向后和向前兼容性：
表 3. 在 RHEL 和 SLES 发行版中的 32 位和 64 位兼容性
| 发行版 | 32 位 | 64 位 |
|---|---|---|
| RHEL3 > RHEL4 | 向前兼容 | 向前兼容 |
| RHEL4 < RHEL3 | 向后兼容 | 向后兼容 |
| SLES9 > SLES8 | 向前兼容 | NA |
| SLES8 < SLES9 | NA | NA |
优化性能
2.6 内核和 POWER6 架构包含能够改进应用程序的性能的特性。性能的改进得益于不同的库、处理器特性和编译器更新。有一些性能改进不需要修改应用程序，而另一些性能改进需要重 新编译源代码。记住，重新编译以获得性能改进可能会损害二进制文件在某些环境中的兼容性。这个小节提供一些例子，它们展示能够改进应用程序性能的 2.6 内核新特性和 POWER6 架构。
NUMA
Non-uniform Memory Access (NUMA) 是针对 Linux on POWER 在 2.6 内核中引入的，这个特性在 RHEL5 和 SLES10 的最新版本中得到进一步优化。NUMA 解决了系统中的某些处理器因为总线位置不同到达特定内存区域的时间要比其他处理器长的问题。NUMA 通过在每个总线使用更多内存总线和更少处理器来减少系统共享内存总线的争用。尽管这在包含少量处理器的系统中作用不明显，但它能够在系统包含大量处理器时 改善性能。
在 Linux 2.6.15 内核中，NUMA 优化通过指定仅本地处理器能够访问内存，从而改进了跨大型系统（处理器核在 4-8 个以上）运行的工作负载的性能。如果处理器正在查找存储在相邻的 cell board 上的内存中的数据，Linux 2.6.16 内核能够获取该信息并将其移动到本地内存中（运行速度更快），然后在本地内存中执行所需的操作，而不需重新启动该操作。
由于 POWER5 和 POWER6 架构能够扩展到 64 位处理器，大部分应用程序都得益于 2.6 内核级别的 NUMA 支持。设法提高性能的应用程序可以使用 user-land NUMA API。RHEL4 附带了 user-land NUMA API，以及更多关于如何在 NUMA Group 主页使用这些 API 的信息（参考资料 部分提供相关链接）。
使用 Linux 2.6.16 内核时，必须根据共享内存的分配方式进行一些更改。如果处理器正在查找存储在相邻的 cell board 上的内存中的数据，Linux 2.6.16 内核能够获取该信息并将其移动到本地内存中（运行速度更快），然后在本地内存中执行所需的操作，而不需重新启动该操作。
编译器改进
您可以考虑重新编译以利用 Linux on POWER 的最新编辑器的新特性带来的性能优势。现在，高性能编译器 IBM XL C/C++ Version 8 可以在基础级别的 RHEL4、SLES9 和 SLES10 上使用。IBM XL C/C++ Version 9 可以在 RHEL5 及其更新、SLES10 SP1 和 SP2 上使用。Version 9 添加了针对基于 POWER6 处理器的系统的性能改进。
-qarch 和 -qtune 选项用于为各自的架构优化性能。例如，要优化 POWER6 的性能，使用 -qarch=pwr6 和 -qtune=pwr6。此外，还引入了 -qtune=balanced 选项。这个选项与 -qarch=pwr5（或 pwr5x）一起使用时，将生成可以在 POWER5 和 POWER6 系统上运行的二进制文件，但包含能够改进 POWER6 性能的调度改进。Version 9 还包含对 AltiVec Vector Multimedia Extensions (VMX) 的支持，VMX 最初是在 IBM PowerPC 970 处理器上提供的，现在通过 -qaltivec 选项整合到 POWER6 产品系列。
GNU Compiler Collection 包含针对多种不同语言的编译器。版本 3.3 到 4.1 得到了改进，包括对其 C 编译器 gcc 的特定于 POWER6 的优化。-mcpu=power6 和 -mtune=power6 标志现在得到支持，从而导致出现针对 POWER6 架构的注册表使用和指令调度参数。此外，还包含针对 IBM PowerPC 970 和 IBM POWER6 处理器的 VMX 向量扩展，它们能够提升向量化代码的性能。尽管这些优化选项在各自的架构上改善了性能，但它们可能损害应用程序在其他平台上的二进制兼容性。
可以在 developerWorks 文章 “How to use IBM XL C/C++ Advanced Edition V8.0 for Linux on POWER: A guide for GCC users” 上找到更多关于在 Linux on POWER 上使用 XL C/C++ 编辑器的信息。
SMT
当迁移到基于 2.6 的 Linux 内核时，Simultaneous Multi-threading (SMT) 还可以提供另一项性能收益。SMT 在 POWER6 上得到支持，并且大大改进了多线程应用程序的性能。POWER6 处理器有两个能够在每个处理器周期发出多条指令的硬件指令线程，从而改善了性能。不过，SMT 可能损害线程不是很多的应用程序的性能。可以在 Linux 内核启动时向其传递 smt-enabled=off 禁用 SMT。
其他 2.6 内核改进
2.6 内核在 RHEL4 和 SLES9 中引入了以下性能改进，并且在 RHEL5 和 SLES10 版本中得到进一步改进：
- 可以扩展到 64 位 SMP POWER6 处理器的可伸缩性。
- 对内存密集型应用程序的大页支持，允许 16MB 的页大小，同时也提供传统的 4KB 页大小。
- 在 Red Hat Enterprise Linux 5 中引入 64KB 的页大小。
- 虚拟内存子系统改进，包括在内存压力比较大的系统中提供的反向映射算法。
- 块 I/O 和异步 I/O 改进。
|
从 RHEL4 迁移到 RHEL5
Red Hat 在 RHEL4 和 RHEL5 之间维护了一个稳定的 ABI，因此可以在这两个版本之间顺利地迁移应用程序。不过，为了确保二进制兼容性，Red Hat 建议您将您的应用程序接口链接到它们所定义的核心库。核心库列表包括：
- libc、libgcc、libstdc++、libdl、libm、libutil、libcrypt、libz、libpthread 和 libncurses
- libX11、libXext、libXt、libICE、libSM 和 libGL
- libgtk、libgdk、libgdk_pixmap、libpango、libatk、libglib、libgmodule、libgthread、libgnomeprint、libgnomeprintui、libgconf 和 libglade
在文章 “Red Hat Enterprise Linux 4 Application Compatibility” 中讨论了核心库和其他兼容性问题（参考资料 部分提供相关链接）。尽管这个文档阐述的是 RHEL4 中的兼容性，但其中的概念和理念适用于 RHEL5 中的应用程序兼容性问题。使用核心库之外的其他库的应用程序仍然可以实现兼容性，但需要进一步执行回归测试。应用程序不保留二进制兼容性的情况包括，应用 程序静态地链接到其他库、依赖内核级别接口，或与 POSIX 标准或 64 位 POWER ABI 定义冲突。
不仅 ABI 在 RHEL4 和 RHEL5 之间保持稳定，并且 RHEL5 中的许多其他 2.6 内核特性也与 RHEL4 兼容。这就允许 RHEL4 应用程序现成地利用 RHEL5 中包含的 Simultaneous Multi-threading (SMT) 和 Native Posix Thread Library (NPTL) 等特性获得性能改进，而不需要重新编译它们的源代码。这些应用程序还可以利用 2.6 内核中的性能改进，如本文前面所述。
不过，在 RHEL5 中的以下两方面进行重新编译能够改进应用程序的性能：
- 对于包含大量处理器的系统，在 RHEL5 中重新编译 NUMA user-land API 会提高性能（如果还没有在 RHEL4 中进行编译的话）。尽管从总体上看应用程序都能够从内核级别 NUMA 支持获得性能改进，但是重新编译这些 user-land API 还可以获得进一步的性能改进。处理器密集型和内存访问频繁的应用程序将获得最大收益，因为 NUMA 减少了处理器访问内存区域的时间。
- 使用 RHEL5 中的最新编辑器进行重新编译时，其他应用程序也可能获得性能改进。这些编译器添加了利用 POWER6 优化的标志，如本文前面所述。
当重新编译应用程序以改善性能时，必须考虑可能损害二进制兼容性的风险。不过，在大部分情况下，将应用程序从 RHEL4 迁移到 RHEL5 时不需要额外的工作。
|
从 SLES9 迁移到 SLES10
从 SLES9 迁移到 SLES10 也是比较顺利的。尽管在 SLES9 中引入了 NPTL 线程模型（不再使用旧的 LinuxThreads 模型），但 NPTL 是 SLES10 中唯一支持的线程模型，因为 Glibc 库不再支持 LinuxThreads。在 “线程模型” 小节描述了更改线程模式导致的问题，解决了从一个线程模式改用另一个线程模式出现的问题。尽管使用更少通用库的非线程应用程序能够更好地维护 SLES 版本之间的二进制兼容性，但必须执行回归测试以确保质量。
对于 RHEL，在某些情况下重新编译源代码可能有利于将要在 SLES10 上运行的应用程序。例如，通过利用 SLES10 中的改进编辑器可以提升应用程序的性能。SMT 也是 SLES10 中的一个新特性，它能够提升包含大量线程的应用程序的性能。
一般而言，大部分非线程应用程序都不会遇到 SLES9 和 SLES10 之间的二进制兼容性问题。不过，在对库和内核版本进行了主要修改之后，最好重新编译源代码，以让应用程序获得最佳的性能。
|
确保跨发行版之间的兼容性
编写能够在多个 Linux 发行版之间移植的应用程序看起来是一个困难的任务，但只要遵循一些简单的实践就可以实现该目的。大部分发行版的最新版本通常包含相同级别的库和内核版本。大部分发行版还使用类似格式的配置和数据文件。
参与 Linux Foundation 的 Linux Standard Base（LSB）项目的 Red Hat 和 Novell 都有一个共同的目标，即开发和推广一组开放标准，以增强 Linux 发行版之间的兼容性，以及支持应用程序以二进制文件的形式在遵循这些标准的系统中运行。此外，LSB 将帮助征集为 Linux 操作系统移植和编写产品的软件供应商。LSB 的关键组件是二进制接口规范，它告诉 Linux 应用程序开发人员构建和配置应用程序的标准方式。该规范特别列出了：
- 通用的打包和安装指南
- 通用的共享库及其选择
- 配置文件
- 文件位置
- 系统命令
- 针对系统接口的 Application Binary Interfaces（应用程序和平台级别）
以下小节详细介绍一些 LSB 规范，并且为编写可以跨不同发行版移植的应用程序提供一些指导原则。
许多 Linux 发行版都包含相同的 ABI 和通用的核心库。不过，每个发行版对核心库的定义都有些不同，因此在声称您的应用程序受特定发行版支持之前，通常需要执行回归测试。
例如，如果您仔细查看 RHEL 和 SLES 发行版中包含的 glibc 库，就会发现 RHEL4 包含的是版本 2.3.4 而 SLES9 包含的是 2.3.3。小的修改通常是添加了修复包，而不是增加新的特性。RHEL4、RHEL5、SLES9 和 SLES10 都包含相似的线程模型，因此链接到通用库的任何应用程序应该都能够在这 3 个操作环境中运行。您还可以在其他发行版（比如 Gentoo 和 Debian）中找到通用库。
File Hierarchy Standard (FHS) 定义文件和目录在通用类 UNIX® 系统上的布局。如果您的应用程序依赖于其他配置和文件，那么可能需要使用 FHS。FHS 的主要目的是为应用程序提供一个通用的位置，以查找标准配置文件。可以在 Filesystem Hierarchy Standard 的主页上找到关于 FHS 的更多信息。（参考资料 部分提供相关链接）。
二进制兼容性考虑事项
尽管根据 ABI 和处理器系列定义了二进制兼容性，但是在确定应用程序是否能够跨多个环境运行时，还有一些其他兼容性事项需要考虑。其中的例子包括线程模型、低级内核依赖 项、中间件和核心库。这个小节讨论这些考虑事项并描述 Linux on POWER 如何处理它们。
线程模式
从 glibc 2.3 发布开始，Linux 中的线程模式就改变了，并且 Linux 内核也从 2.4 版本升级到 2.6 版本。在 glibc 2.2 和内核 2.4 中使用的传统 LinuxThreads 模型已被 Native Posix Thread Library (NPTL) 取代。NPTL 是从头构建的，为包含大量线程的应用程序提供出色的性能。可以在 Red Hat 文章 “The Native POSIX Thread Library for Linux” 找到更多关于 NPTL 规范的详细信息（参考资料 部分提供相关链接）。
SLES8 基于 2.4 内核并保护 LinuxThreads 模型，当尝试运行包含 NPTL 线程模型的 SLES9 上的包含大量线程的应用程序时，它将出现问题。可以通过两种途径解决这个问题：
- 对源代码进行少量修改并根据基于 NPTL 的库进行重新编译，以获得 NPTL 带来的性能改进。可以在 LinuxDevices.com 的文章 “Migrating applications to the 2.6 kernel and NPTL” 找到更多关于从 LinuxThreads 模型迁移到基于 NPTL 模型的信息（参考资料 部分提供相关链接）。
- 设 置 LD_ASSUME_KERNEL 环境变量，它为 SLES9 中的 LinuxThreads 模型提供向后兼容性。通过设置这个环境变量，连接器将认为 2.4 内核运行旧的 LinuxThreads 模型。Red Hat 开发人员 Ulrich Drepper 详细解释了 LD_ASSUME_KERNEL（参考资料 部分提供相关链接）。不过，由于 SLES10 中的 glibc 发生了变化，基于旧的 LinuxThreads 模型的语义的应用程序将不能正常工作，因为在 SLES 10 中旧的 LinuxThreads 模型已经被新的 NPTL 取代。这还意味着 LD_ASSUME_KERNEL 环境变量的值仅能被设置为大于 2.6.4 的值。最好根据更新的 NPTL —— SLES 9 中的默认 NPTL —— 进行测试。
低级内核依赖项
当在不同的操作环境中运行应用程序时，另一个考虑事项是低级内核依赖项。应用程序不兼容的一个例子就是将信息从 /proc 文件系统移动到 sysfs 文件系统，如果应用程序在这些文件系统之一中用硬编码值编写的话。/proc 文件系统最初是一个常驻文件系统，它允许用户空间访问包含信息的内核数据结构，比如系统和设备状态信息。这些信息将从 /proc 文件系统移动到 sysfs 文件系统。/proc 文件系统仍然存在，但它仅包含进程信息。
存储 Universal Serial Bus (USB) 设备列表是将系统信息从 /proc 文件系统移动到 sysfs 文件系统的一个例子。在系统中最初基于内核 2.4 编写的应用程序将在 /proc/bus/usb/devices 目录下找到该设备列表。在迁移到使用 2.6 内核的 sysfs 文件系统之后，该信息被移动到 /sys/bus/usb/devices 目录。这一信息移动将可能导致应用程序不能正常工作。尽管这种情况并不常见，但您应该注意内核级别的这类潜在问题。
中间件和应用程序兼容性
当今的许多应用程序都不是自含的，而是依赖于中间件。中间件是位于两个应用程序之间或位于应用程序和操作系统之间的软件。中间件的例子包括 IBM DB2® Universal Database for Linux、Java™ Development Kit (JDK) 和 IBM WebSphere® 应用程序。开发人员可以决定他们的应用程序支持的中间件版本， 但是中间件提供商决定他们的产品将运行在哪个 Linux 发行版上。可以在 IBM 的 Linux 软件 Web 站点上找到 IBM 的 Linux 中间件列表。（参考资料 部分提供相关链接）。除了中间件之外，应用程序还可能依赖于发行版附带的其他应用程序。其中的例子包括 Apache web 服务器、数据库系统（比如 mysql 和 postgresql）和解释语言（比如 perl 和 python）。
作为一个例子，我们将仔细查看 Java 的使用如何影响应用程序开发人员。Java 中间件包备受关注，因为 Java 的平台独立性使得 Java 应用程序在数量上居高不下。不仅存在不同版本的 JDK 和不同的 JDK 提供商，还存在针对 Linux on POWER 的 32 位和 64 位 JDK。RHEL4 附带了 IBM 32-bit SDK for Linux V1.4.2。RHEL5 附带了 IBM 32-bit SDK for Linux V1.4.2 和 IBM 32-bit SDK for Linux V1.5。SLES9 SP3 附带了 IBM 32-bit SDK for Linux V1.4.2，而 SLES10 SP2 附带了 32-bit IBM SDK V1.4.2 以及 IBM 32-bit 和 64-bit SDK for Linux V1.5。应用程序开发人员必须注意这些差别，避免应用程序仅依赖于在 5.0 版本中可用的特性。
另一个例子是，尽管 Apache web 服务器是非中间件应用程序，但是许多应用程序都依赖它。Apache 的最新版本是 2.2，它附带了 RHEL5 和 SLES10，而 Apache 2.0 附带的是 RHEL4 和 SLES9。如果应用程序包含的特性仅在 Apache 2.2 中可用，那么它们可能与附带 RHEL4 和 SLES9 的 Apache 2.0 不兼容。
核心库
核心库的主要修改也可能导致二进制兼容性问题。向后兼容性是在库之间的主要修改中维护的。这允许应用程序根据特定库的旧版本进行编译，以运行该库的新版本。如果库的两个版本之间出现主要修改，那么根据特定库的最新版本进行编译的应用程序将不能在该库的旧版本上运行。
例如，在包含 glibc 2.3.3 的 SLES9 系统上编译的二进制文件可以在包含 glibc 2.4 的 SLES10 系统上运行，因为 2.4 版本是向后兼容的。不过，在 SLES10 上编译的相同源代码将不能在 SLES9 系统上运行，因为它包含旧的 glibc。仅当您在当前的发行版上开发应用程序，并且想在不提供旧版本兼容库的旧发行版上运行该应用程序时，才会出现这种问题。
|