Linux on POWER：发行版迁移和二进制兼容性考虑事项（3）

look_w

确保跨发行版之间的兼容性编写能够在多个 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 的更多信息。
尽管不能断言能够跨所有 Linux 发行版实现二进制兼容性，但是通过遵循这些实践，至少可以宣称能够在当前的许多发行版上实现二进制兼容性。
二进制兼容性考虑事项尽管根据 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。仅当您在当前的发行版上开发应用程序，并且想在不提供旧版本兼容库的旧发行版上运行该应用程序时，才会出现这种问题。