Inhaltsverzeichnis
openSUSE® ist für 64-Bit-Plattformen verfügbar. Das bedeutet jedoch nicht unbedingt, dass alle enthaltenen Anwendungen bereits auf 64-Bit-Plattformen portiert wurden. openSUSE unterstützt die Verwendung von 32-Bit-Anwendungen in einer 64-Bit-Systemumgebung. Dieses Kapitel gibt einen kurzen Überblick über die Implementierung dieser Unterstützung auf openSUSE-64-Bit-Plattformen. Es wird erläutert, wie 32-Bit-Anwendungen ausgeführt werden (Laufzeitunterstützung) und wie 32-Bit-Anwendungen kompiliert werden sollten, damit sie sowohl in 32-Bit- als auch in 64-Bit-Systemanwendungen ausgeführt werden können. Außerdem finden Sie Informationen zur Kernel-API und es wird erläutert, wie 32-Bit-Anwendungen unter einem 64-Bit-Kernel ausgeführt werden können.
openSUSE für die 64-Bit-Plattformen amd64 und Intel 64 ist so konzipiert, dass bestehende 32-Bit-Anwendungen sofort in der 64-Bit-Umgebung ausgeführt werden können. Diese Unterstützung bedeutet, dass Sie weiterhin Ihre bevorzugten 32-Bit-Anwendungen verwenden können und nicht warten müssen, bis ein entsprechender 64-Bit-Port verfügbar ist.
Konflikte zwischen Anwendungsversionen | |
---|---|
Wenn eine Anwendung sowohl für 32-Bit- als auch für 64-Bit-Umgebungen verfügbar ist, führt die parallele Installation beider Versionen zwangsläufig zu Problemen. Entscheiden Sie sich in diesen Fällen für eine der beiden Versionen und installieren und verwenden Sie nur diese. Eine Ausnahme von dieser Regel ist PAM (Pluggable Authentication Modules). Während des Authentifizierungsprozesses verwendet openSUSE PAM als Schicht für die Vermittlung zwischen Benutzer und Anwendung. Auf einem 64-Bit-Betriebssystem, das auch 32-Bit-Anwendungen ausführt, ist es stets erforderlich, beide Versionen eines PAM-Moduls zu installieren. |
Für eine korrekte Ausführung benötigt jede Anwendung eine Reihe von Bibliotheken. Leider sind die Namen für die 32-Bit- und 64-Bit-Versionen dieser Bibliotheken identisch. Sie müssen auf andere Weise voneinander unterschieden werden.
Um die Kompatibilität mit der 32-Bit-Version aufrechtzuerhalten, werden die Bibliotheken am selben Ort im System gespeichert wie in der 32-Bit-Umgebung. Die 32-Bit-Version von libc.so.6
befindet sich sowohl in der 32-Bit- als auch in der 64-Bit-Umgebung unter /lib/libc.so.6
.
Alle 64-Bit-Bibliotheken und Objektdateien befinden sich in Verzeichnissen mit dem Namen lib64
. Die 64-Bit-Objektdateien, die sich normalerweise unter /lib
und /usr/lib
befinden, werden nun unter /lib64
und /usr/lib64
gespeichert. Unter /lib
und /usr/lib
ist also Platz für die 32-Bit-Bibliotheken, sodass der Dateiname für beide Versionen unverändert bleiben kann.
Unterverzeichnisse von 32-Bit-Verzeichnissen namens /lib
, deren Dateninhalt nicht von der Wortgröße abhängt, werden nicht verschoben. Das Schema entspricht LSB (Linux Standards Base) und FHS (File System Hierarchy Standard).
Eine Doppelarchitektur-Entwicklungswerkzeugkette (Biarch Development Toolchain) ermöglicht die Erstellung von 32-Bit- und 64-Bit-Objekten. Standardmäßig werden 64-Bit-Objekte kompiliert. 32-Bit-Objekte können durch Verwendung spezieller Flaggen erstellt werden. Bei GCC lautet diese Flagge -m32
.
Alle Header-Dateien müssen in architekturunabhängiger Form geschrieben werden. Die installierten 32-Bit- und 64-Bit-Bibliotheken müssen eine API (Anwendungsprogrammschnittstelle) aufweisen, die zu den installierten Header-Dateien passt. Die normale openSUSE-Umgebung wurde nach diesem Prinzip gestaltet. Bei manuell aktualisierten Bibliotheken müssen Sie diese Probleme selbst lösen.
Um bei einer Doppelarchitektur Binärdateien für die jeweils andere Architektur zu entwickeln, müssen die entsprechenden Bibliotheken für die zweite Architektur zusätzlich installiert werden. Diese Pakete heißen rpmname-32bit
. Außerdem benötigen Sie die entsprechenden Header und Bibliotheken aus den rpmname-devel
-Paketen und die Entwicklungsbibliotheken für die zweite Architektur aus rpmname-devel-32bit
.
Die meisten Open Source-Programme verwenden eine autoconf-basierte Programmkonfiguration. Um mit autoconf ein Programm für die zweite Architektur zu konfigurieren, überschreiben Sie die normalen Compiler- und Linker-Einstellungen von autoconf, indem Sie das Skript configure mit zusätzlichen Umgebungsvariablen ausführen.
Das folgende Beispiel bezieht sich auf ein x86_64-System mit x86 als zweiter Architektur.
Verwenden Sie den 32-Bit-Compiler:
CC="gcc -m32"
Weisen Sie den Linker an, 32-Bit-Objekte zu verarbeiten (verwenden Sie stets gcc als Linker-Frontend):
LD="gcc -m32"
Legen Sie den Assembler für die Erstellung von 32-Bit-Objekten fest:
AS="gcc -c -m32"
Geben Sie die Linker-Flags an, wie zum Beispiel den Standort von 32-Bit-Bibliotheken:
LDFLAGS="-L/usr/lib"
Geben Sie den Standort für die 32-Bit-Objektcode-Bibliotheken an:
--libdir=/usr/lib
Geben Sie den Standort für die 32-Bit-X-Bibliotheken an:
--x-libraries=/usr/lib
Nicht alle diese Variablen werden für jedes Programm benötigt. Passen Sie sie an das entsprechende Programm an.
CC="gcc -m32" LDFLAGS="-L/usr/lib;" ./configure --prefix=/usr --libdir=/usr/lib --x-libraries=/usr/lib make make install
Die 64-Bit-Kernels für x86_64 bieten sowohl eine 64-Bit- als auch eine 32-Bit-Kernel-ABI (binäre Anwendungsschnittstelle). Letztere ist mit der ABI für den entsprechenden 32-Bit-Kernel identisch. Das bedeutet, dass die 32-Bit-Anwendung mit dem 64-Bit-Kernel auf die gleiche Weise kommunizieren kann wie mit dem 32-Bit-Kernel.
Die 32-Bit-Emulation der Systemaufrufe für einen 64-Bit-Kernel unterstützt nicht alle APIs, die von Systemprogrammen verwendet werden. Dies hängt von der Plattform ab. Aus diesem Grund muss eine kleine Zahl von Anwendungen, wie beispielsweise lspci, kompiliert werden.
Ein 64-Bit-Kernel kann nur 64-Bit-Kernel-Module laden, die speziell für diesen Kernel kompiliert wurden. 32-Bit-Kernel-Module können nicht verwendet werden.
Kernel-ladbare Module | |
---|---|
Für einige Anwendungen sind separate, Kernel-ladbare Module erforderlich. Wenn Sie vorhaben, eine solche 32-Bit-Anwendung in einer 64-Bit-Systemumgebung zu verwenden, wenden Sie sich an den Anbieter dieser Anwendung und an Novell, um sicherzustellen, dass die 64-Bit-Version des Kernel-ladbaren Moduls und die kompilierte 32-Bit-Version der Kernel-API für dieses Modul verfügbar sind. |