Contents
openSUSE® is available for 64-bit platforms. This does not necessarily mean that all the applications included have already been ported to 64-bit platforms. openSUSE supports the use of 32-bit applications in a 64-bit system environment. This chapter offers a brief overview of how this support is implemented on 64-bit openSUSE platforms. It explains how 32-bit applications are executed (runtime support) and how 32-bit applications should be compiled to enable them to run both in 32-bit and 64-bit system environments. Additionally, find information about the kernel API and an explanation of how 32-bit applications can run under a 64-bit kernel.
openSUSE for the 64-bit platforms amd64 and Intel 64 is designed so that existing 32-bit applications run in the 64-bit environment “out-of-the-box.” This support means that you can continue to use your preferred 32-bit applications without waiting for a corresponding 64-bit port to become available.
Conflicts between Application Versions | |
---|---|
If an application is available both for 32-bit and 64-bit environments, parallel installation of both versions is bound to lead to problems. In such cases, decide on one of the two versions and install and use this. An exception to this rule is PAM (pluggable authentication modules). openSUSE uses PAM in the authentication process as a layer that mediates between user and application. On a 64-bit operating system that also runs 32-bit applications it is necessary to always install both versions of a PAM module. |
To be executed correctly, every application requires a range of libraries. Unfortunately, the names for the 32-bit and 64-bit versions of these libraries are identical. They must be differentiated from each other in another way.
To retain compatibility with the 32-bit version, the libraries are stored
at the same place in the system as in the 32-bit environment. The 32-bit
version of libc.so.6
is located under
/lib/libc.so.6
in both the 32-bit and 64-bit
environments.
All 64-bit libraries and object files are located in directories called
lib64
. The 64-bit object files that you would
normally expect to find under /lib
and
/usr/lib
are now found under
/lib64
and /usr/lib64
. This
means that there is space for the 32-bit libraries under
/lib
and /usr/lib
, so the
filename for both versions can remain unchanged.
Subdirectories of 32-bit /lib
directories which
contain data content that does not depend on the word size are not moved.
This scheme conforms to LSB (Linux Standards Base) and FHS (File System
Hierarchy Standard).
A biarch development tool chain allows generation of 32-bit and 64-bit
objects. The default is to compile 64-bit objects. It is possible to
generate 32-bit objects by using special flags. For GCC, this special
flag is -m32
.
All header files must be written in an architecture-independent form. The installed 32-bit and 64-bit libraries must have an API (application programming interface) that matches the installed header files. The normal openSUSE environment is designed according to this principle. In the case of manually updated libraries, resolve these issues yourself.
To develop binaries for the other architecture on a biarch architecture,
the respective libraries for the second architecture must additionally be
installed. These packages are called
rpmname-32bit
. You also need the
respective headers and libraries from the
rpmname-devel
packages and the
development libraries for the second architecture from
rpmname-devel-32bit
.
Most open source programs use an autoconf-based program configuration. To use autoconf for configuring a program for the second architecture, overwrite the normal compiler and linker settings of autoconf by running the configure script with additional environment variables.
The following example refers to an x86_64 system with x86 as the second architecture.
Use the 32-bit compiler:
CC="gcc -m32"
Instruct the linker to process 32-bit objects (always use gcc as the linker front-end):
LD="gcc -m32"
Set the assembler to generate 32-bit objects:
AS="gcc -c -m32"
Specify linker flags, such as the location of 32-bit libraries, for example:
LDFLAGS="-L/usr/lib"
Specify the location for the 32-bit object code libraries:
--libdir=/usr/lib
Specify the location for the 32-bit X libraries:
--x-libraries=/usr/lib
Not all of these variables are needed for every program. Adapt them to the respective program.
CC="gcc -m32" LDFLAGS="-L/usr/lib;" ./configure --prefix=/usr --libdir=/usr/lib --x-libraries=/usr/lib make make install
The 64-bit kernels for x86_64 offer both a 64-bit and a 32-bit kernel ABI (application binary interface). The latter is identical with the ABI for the corresponding 32-bit kernel. This means that the 32-bit application can communicate with the 64-bit kernel in the same way as with the 32-bit kernel.
The 32-bit emulation of system calls for a 64-bit kernel does not support all the APIs used by system programs. This depends on the platform. For this reason, a small number of applications, like lspci, must be compiled.
A 64-bit kernel can only load 64-bit kernel modules that have been specially compiled for this kernel. It is not possible to use 32-bit kernel modules.
Kernel-loadable Modules | |
---|---|
Some applications require separate kernel-loadable modules. If you intend to use such a 32-bit application in a 64-bit system environment, contact the provider of this application and Novell to make sure that the 64-bit version of the kernel-loadable module and the 32-bit compiled version of the kernel API are available for this module. |