systemd
Daemonjournalctl
: Query the systemd
Journaludev
openSUSE® Leap 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 Leap 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 Leap 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 Leap 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.
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 Leap 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 file name 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).
All 64-bit architectures support the development of 64-bit objects. The
level of support for 32-bit compiling depends on the architecture. These are
the various implementation options for the toolchain from GCC (GNU Compiler
Collection) and binutils, which include the assembler as
and the linker ld
:
Both 32-bit and 64-bit objects can be generated with a biarch development
toolchain. A biarch development toolchain allows generation of 32-bit and
64-bit objects. The compilation of 64-bit objects is the default on almost
all platforms. 32-bit objects can be generated if special flags are used.
This special flag is -m32
for GCC. The flags for the
binutils are architecture-dependent, but GCC transfers the correct flags to
linkers and assemblers. A biarch development toolchain currently exists for
amd64 (supports development for x86 and amd64 instructions), for z Systems
and for POWER. 32-bit objects are normally created on the POWER
platform. The -m64
flag must be used to generate 64-bit
objects.
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 Leap 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
.
For example, to compile a program that uses libaio
on a
system whose second architecture is a 32-bit architecture
(x86_64), you need the following
RPMs:
32-bit runtime package
Headers and libraries for 32-bit development
64-bit runtime package
64-bit development headers and libraries
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.
An example configure
call to compile a native 32-bit
application on x86_64 could
appear as follows:
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 AMD64/Intel 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, few 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.
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 SUSE 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.