Linux on POWER：發行版遷移和二進位相容性考慮事項

瞭解二進位相容性以及它與運行在 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 網頁伺服器是非中介軟體應用程式，但是許多應用程式都依賴它。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。僅當您在當前的發行版上開發應用程式，並且想在不提供舊版本相容庫的舊發行版上運行該應用程式時，才會出現這種問題。