3.2. 互換性

互換性により、コンピューターの稼働環境が異なるインスタンスにおいてバイナリーオブジェクトとソースコードの移植性があるかどうかが分かります。公式には、Red Hat は現行バージョンとそれ以前の 2 つのバージョンをサポートします。つまり、Red Hat Enterprise Linux 4 および Red Hat Enterprise Linux 5 で作成されたアプリケーションは、それが Red Hat ガイドラインに準拠している限り (例えば、ホワイトリスト化された記号を使用)、Red Hat Enterprise Linux 6 で稼働します。
Red Hat は、エンタープライズプラットフォームとしてお客様がそのアプリケーションの長期的開発に依存していることを理解しています。このため、互換性ライブラリの助けを用いて C/C++ ライブラリに対して構築されたアプリケーションは、10 年間サポートが継続されます。
互換性には以下の 2 種類があります。
ソースの互換性
ソースの互換性は、コードが稼働環境の異なるインスタンスにおいて一貫性があり予測可能な方法でコンパイルおよび実行することを指定します。この種類の互換性は、特定の Application Programming Interfaces (API) との適合性で定義されます。
バイナリーの互換性
バイナリーの互換性は、実行可能ファイルおよび Dynamic Shared Objects (動的共有オブジェクト: DSO) の形式でコンパイル済みバイナリーが稼働環境の異なるインスタンスで正確に実行することを指定します。この種類の互換性は、特定の Application Binary Interfaces (ABI) との適合性で定義されます。
この点と、コアおよび非コアライブラリー間の全レベルでの互換性についての詳細情報は、https://access.redhat.com/support/policy/updates/errata/から Red Hat Enterprise Linux のサポート対象リリースを参照してください。また、Red Hat Enterprise Linux の互換性ポリシー全般は、https://access.redhat.com/solutions/5154 を参照してください。

3.2.1. 静的リンク

静的リンクは、すべての Red Hat Enterprise Linux リリースで使用しないことが強く推奨されます。静的リンクは解決するよりもはるかに多くの問題を生み出し、ぜひとも避けるべきです。
静的リンクの主な欠点は、それが構築されたシステム上での動作のみが保証されており、それも glibc もしくは libstdc++ (C++ の場合) の次回リリースまでです。静的構築では、前方もしくは後方互換性がありません。さらに、以降のライブラリーの更新におけるセキュリティ修正は、影響のある静的にリンクされた実行可能ファイルが再度リンク化されない限り、利用可能にはなりません。
静的リンクを避ける他の理由は以下のとおりです。
  • メモリフットプリントが大きい。
  • アプリケーションの起動時間が長い。
  • 静的リンクだと glibc 機能が限定される。
  • ロードアドレスのランダム化などのセキュリティ対策が使用できない。
  • glibc 外の共有オブジェクトの動的ローディングがサポートされていない。
静的リンクを避けるさらなる理由については、Static Linking Considered Harmful を参照してください。