Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server 11 SP4

9 32-Bit and 64-Bit Applications in a 64-Bit System Environment

SUSE® Linux Enterprise Server is available for several 64-bit platforms. This does not necessarily mean that all the applications included have already been ported to 64-bit platforms. SUSE Linux Enterprise Server 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 SUSE Linux Enterprise Server 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.

SUSE Linux Enterprise Server for the 64-bit platforms ia64, ppc64, System z and x86_64 is designed so that existing 32-bit applications run in the 64-bit environment out-of-the-box. The corresponding 32-bit platforms are x86 for ia64, ppc for ppc64, and x86 for x86_64. 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. The current ppc64 system runs most applications in 32-bit mode, but you can run 64-bit applications.

9.1 Runtime Support

Important
Important: 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). SUSE Linux Enterprise Server 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).

ipf The 64-bit libraries for ia64 are located in the standard lib directories, there is neither a lib64 directory nor a lib32 directory. ia64 executes 32-bit x86 code under an emulation. A set of basic libraries is installed in /emul/ia32-linux/lib and /emul/ia32-linux/usr/lib.

9.2 Software Development

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 tool chain from GCC (GNU Compiler Collection) and binutils, which include the assembler as and the linker ld:

Biarch Compiler

Both 32-bit and 64-bit objects can be generated with a biarch development tool chain. A biarch development tool chain 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 tool chain currently exists for amd64 (supports development for x86 and amd64 instructions), for System z and for ppc64. 32-bit objects are normally created on the ppc64 platform. The -m64 flag must be used to generate 64-bit objects.

No Support

SUSE Linux Enterprise Server does not support the direct development of 32-bit software on all platforms. To develop applications for x86 under ia64, use the corresponding 32-bit version of SUSE Linux Enterprise Server.

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 SUSE Linux Enterprise Server environment is designed according to this principle. In the case of manually updated libraries, resolve these issues yourself.

9.3 Software Compilation on Biarch Platforms

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 or rpmname-x86 (for ia64) if the second architecture is a 32-bit architecture or rpmname-64bit if the second architecture is a 64-bit architecture. 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 or rpmname-devel-64bit.

For example, to compile a program that uses libaio on a system whose second architecture is a 32-bit architecture (x86_64 or System z), you need the following RPMs:

libaio-32bit

32-bit runtime package

libaio-devel-32bit

Headers and libraries for 32-bit development

libaio

64-bit runtime package

libaio-devel

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. Examples for ppc64 with ppc as the second architecture would be similar. This example does not apply to ia64 where you cannot build 32-bit packages.

  1. Use the 32-bit compiler:

    CC="gcc -m32"
  2. Instruct the linker to process 32-bit objects (always use gcc as the linker front-end):

    LD="gcc -m32"
  3. Set the assembler to generate 32-bit objects:

    AS="gcc -c -m32"
  4. Specify linker flags, such as the location of 32-bit libraries, for example:

    LDFLAGS="-L/usr/lib"
  5. Specify the location for the 32-bit object code libraries:

    --libdir=/usr/lib
  6. 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, ppc64 or System z could appear as follows:

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

9.4 Kernel Specifications

The 64-bit kernels for x86_64, ppc64 and System z 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 on non-ppc64 platforms as 64-bit programs to function properly. On IBM System z, not all ioctls are available in the 32-bit kernel ABI.

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.

Tip
Tip: 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 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.

Print this page