重要: アプリケーションバージョン間の競合

アプリケーションが32ビットと64ビットの両方の環境で使用可能な場合に、両方のバージョンを同時にインストールすると問題が生じます。そのような場合は、2つのバージョンのどちらかだけをインストールして使用してください。

PAM(プラグ可能認証モジュール)は、このルールの例外です。SUSE Linux Enterprise Serverは、ユーザとアプリケーションを仲介するレイヤとしての認証プロセスでPAMを使用します。また、 32ビットアプリケーションも実行する64ビットオペレーティングシステムでは、常に両バージョンのPAMモジュールをインストールする必要があります。

正しく実行するために、すべてのアプリケーションにはライブラリが必要です。しかし残念ながら、32ビットバージョンと64ビットバージョンのライブラリの名前は同じです。そのため、ライブラリを別の方法で区別する必要があります。

32ビットバージョンとの互換性を維持するために、ライブラリは32ビット環境の場合と同じシステム内の場所に格納されます。libc.so.6の32ビットバージョンは、32ビットと64ビットのどちらの環境でも/lib/libc.so.6の下にあります。

64ビットのすべてのライブラリとオブジェクトファイルは、lib64というディレクトリにあります。通常、/libおよび/usr/libの下にある64ビットのオブジェクトファイルは、/lib64および/usr/lib64の下にあります。つまり、両方のバージョンのファイル名を変更しなくても済むように、32ビットライブラリ用の領域は/libおよび/usr/libの下になっています。

ワードサイズに依存しないデータコンテンツを持つ、32ビットの/libディレクトリ中のサブディレクトリは移動されません。このスキームは、LSB (Linux Standards Base)とFHS (File System Hierarchy Standard)に準拠しています。

すべての64ビットアーキテクチャで、64ビットオブジェクトの開発がサポートされています。32ビットコンパイル機能のサポートレベルは、アーキテクチャによって異なります。32ビットコンパイル機能は、GCC (GNU Compiler Collection)やbinutilsによるツールチェーンの各種実装オプションになっています。Binutilsには、アセンブラasとリンカーldが含まれています。

すべてのヘッダファイルは、アーキテクチャに依存しない形式で作成する必要があります。インストール済みの32ビットと64ビットのライブラリには、インストール済みのヘッダファイルに対応するAPI (アプリケーションプログラミングインタフェース)が必要です。標準のSUSE Linux Enterprise Server環境は、この原則に従って設計されています。ライブラリを手動で更新した場合は、各自でAPIの問題を解決してください。

biarchアーキテクチャで他のアーキテクチャ向けのバイナリを開発するには、対象のアーキテクチャのそれぞれのライブラリをさらにインストールする必要があります。こうしたパッケージは、対象のアーキテクチャが-32ビットアーキテクチャである場合はrpmname- 32bitまたはrpmname-x86(ia64の場合)と呼ばれ、対象のアーキテクチャが-64ビットアーキテクチャである場合はrpmname- 64bitと呼ばれます。さらに、rpmname-develパッケージからそれぞれのヘッダとライブラリ、また、rpmname-devel-32bitまたはrpmname-devel-64bitから対象のアーキテクチャ向けの開発ライブラリも必要です。

たとえば、対象のアーキテクチャが32ビットアーキテクチャ(x86_64またはSystem z)であるシステムでlibaioを使用するプログラムをコンパイルするには、次のRPMが必要です。

ほとんどのオープンソースプログラムでは、autoconfベースのプログラム設定が使用されています。対象のアーキテクチャ向けプログラムの設定にautoconfを使用するには、autoconfの標準のコンパイラとリンカーの設定に上書きするために、さらに環境変数を指定してconfigureスクリプトを実行します。

次の例は、対象のアーキテクチャとしてx86を採用しているx86_64システムを示しています。対象のアーキテクチャとしてppcを採用しているppc64の場合も同様です。この例は、32ビットパッケージをビルドできないia64には適用されません。

こうした変数のすべてがどのプログラムにも必要なわけではありません。それぞれのプログラムに合わせて使用してください。

x86__64、ppc64、またはSystem zでネイティブの32ビットアプリケーションをコンパイルする場合の、configureコールの例を次に示します。

CC="gcc -m32"
LDFLAGS="-L/usr/lib;"
./configure --prefix=/usr --libdir=/usr/lib --x-libraries=/usr/lib
make
make install

x86_64、ppc_64およびSystem z向けの64ビットカーネルには、64ビットと32ビットのカーネルABI (アプリケーションバイナリインタフェース)が用意されています。32ビットのカーネルABIは、該当する32ビットカーネルのABIと同じものです。つまり、32ビットアプリケーションが、32ビットカーネルの場合と同様に64ビットカーネルと通信できるということです。

64ビットカーネルのシステムコールの32ビットエミュレーションでは、システムプログラムで使用されるすべてのAPIをサポートしていません。ただし、このサポートの有無はプラットフォームによって異なります。このため、lspciなどの少数のアプリケーションは、正しく機能するように64ビットプログラムとして非ppc 64プラットフォームでコンパイルする必要があります。IBM System zでは、32ビットカーネルABIで利用できないioctlsがあります。

64ビットカーネルでは、このカーネル用に特別にコンパイルされた64ビットカーネルモジュールしかロードできません。したがって、32ビットカーネルモジュールを使用することはできません。

ヒント: カーネルロード可能モジュール

一部のアプリケーションには、カーネルでロード可能な個々のモジュールが必要です。64ビットシステム環境でそのような32ビットアプリケーションを使用する予定がある場合は、このアプリケーションおよびSUSEのプロバイダに問い合わせて、このモジュール向けのカーネルでロード可能な64ビットバージョンのモジュールと32ビットコンパイルバージョンのカーネルAPIを入手できるかを確認してください。