Re: PROPOSED: 32/64 bit coexistance
I've just added a few paragraphs adding those points that have been
raised. This is not as smooth as the original version and might need
further editing but I hope the contents is clear.
What do you think? Have we reached consensus - or where is still room
for clarification?
Andreas
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
32/64bit executable coexistence on architectures with
32/64bit backward compatibility
1. Introduction
Linux has been ported to serveral different architectures
and is now available for both 32bit and 64bit processors.
Some of these architectures and their implementations in
hardware already allow or will allow parallel execution of
32bit and 64bit applications in the very same single
operating system instance. As the 32bit and 64bit instances
of libraries like glibc usually are named identically due to
the same source code base, they cannot reside in the same
directory of the Linux file system hierarchy.
In general, we have to differentiate between code models and data
models. For code models there is always the native code model and
also emulations of other architectures. Data models differentiate
between the size of pointers and integers, the two prominent data
models are ILP32 (integer, longs and pointers are 32 bit) and LP64
(integers are 32 bit, longs and pointers are 64 bit). In the
following discussion a 64-bit library used the LP64 and the native
code model, a 32-bit library uses ILP32 and the native code model.
A decision has to be made about the location and naming
conventions for the dedicated libraries and whether
compatibility between existing 32 bit packages and new 64
bit systems is desired.
An approach that is commonly agreed and followed by all
parties will result in smooth interoperability vs. increased
efforts due to different directory structures on different
architectures and different Linux OS vendor systems.
2. Discussion
Until now two significant 64bit Linux ports are available
using a 64bit kernel and 64bit userland: Compaq Alpha and
Intel Itanium based systems. Theses ports are focused to
exploit and use the 64bit architecure.
The new emerging or potential ports for AMD x86-64, IBM
pSeries / iSeries Power3/4, SPARC32/64 and IBM zSeries
approach the 64bit area in different ways and are capable
for a multi library approach (32/64bits):
* AMD x86-64 can be regarded as transparently extending the
32bit architecture by 64bit features
* ipSeries today only have 32bit based kernels and userland
available, but are expected to have 64bit kernel in the
near future (same as x86-64)
* SPARC runs 64bit and 32bit based kernels, userland is
mostly 32bit based, with 64bit based libs available, too
(same as x86-64, ipSeries)
* S/390 and zSeries can be supported in either way: S/390 by
31/32bit kernel and userland, zSeries with 64bit kernel
and userland.
Applications can be build either using 32bit or 64bit
libraries and are compiled to use dedicated shared libraries
of each type. If one application runs in 64bit, it can only
use 64bit libraries. The same applies for 32bit. There's no
way to use both 32-bit and 64-bit libraries in one
application.
Loading the depending functions and libraries is done during
execution by the dynamic loader. It needs to know dedicated
file system pathes to search for available libraries.
The Linux File Hierarchy Standard FHS Version 2.2 final
(http://www.pathname.com/fhs/) supports both file location
and naming conventions for such libraries: /lib32 and /lib64
to place 32bit and 64bit libraries.
Relevant paragraphs are: [...] 3.10.2 Requirements ->
footnote 12: This is commonly used for 64-bit or 32-bit
support on systems which support multiple binary formats,
but require libraries of the same name. In this case, /lib32
and /lib64 might be the library directories, and /lib a
symlink to one of them. [...]
Note: FHS does not mention the case of one architecure being
capable different binaries like /libPPC or /libPPC64 (but
provides a naming convention scheme for it: /libNN)
On 'pure' 64bit systems the natural location would be /lib
for those libraries and 32bit libs would be placed in /lib32
(Linux for iA64, L/Alpha, and L/zSeries have started this
way).
While this naming conventions seems quite obvious and
natural it is not backward compatible: existing 32bit
applications will install and search their 32bit shared libs
in /lib which will only contain 64bit libs. A symbolic link
or renaming to /lib -> /lib32 will conflict with installed
64bit applications on the system.
3. Recommendations
We recommend the use of /lib64 to contain the 64bit
libraries on multi-library capable 64bit Linux ports and a
/lib which isn't a symbolic link but a real directory to
contain 32bit libraries for the following reasons:
* existing 32bit applications will install with rpm directly
and run without a change in a 64bit system (zSeries and
sparc64 today)
* rpm is known to fail on nested symlinks within in pathes
on updating those directories; therefore /lib should not
be a link to /lib32.
* dedicated directory structure for a 32bit subsystem does
not integrate smoothly into the existing FHS / (root)
directory structure. FHS today does not allow new
directories below / (root). Possible options would be
/opt/emu32, /usr/emu32 ... rpm needs to install
accordingly, too, but will not work with todays versions
(this could be achieved with intelligent wrapper scripts
analysing the target system but this does not reflect a
generic approach). Addtional problems might show up since
/opt might not be available when booting up the system.
* existing commercial binary-only applications like
middleware and applications are and might only be
available as 32-bit binaries for the time being due to
porting efforts and quality assurance cycles.
* exisiting binary executable code generating tool chain
(gcc, binutils, glibc) already are capable to handle the
/lib64 approach
* /lib: consistent scheme for all 32bit systems and x86-64,
sparc64, ppc64, zSeries (s390x).
* iA64 today has a 32bit emulation mode, but 64bit is the
(only) favored one; Alpha is too long established. (64bit
libs will go to /lib)
* only few applications or middleware will benefit from full
64bit support in general (databases, ERP systems,
applications using large memory caches for speed, numeric
intense applications, ...)
* 32bit applications tend to have a smaller memory footprint
due code/data alignment in physical memory, thus total
memory usage is more efficient on large systems with
multiple Linux system instances (iSeries, zSeries)
* compiler and toolchain can be used to build 32-bit
applications on a 64-bit architecture; they can be
transferred to 32-bit architecture hardware (cross
development with tested executables) without further
changes.
4. Emulations of Other Architectures
For emulation of other architectures, the FHS should be extended to
use the /emul/ prefix as /emul/<arch>-<opsys>, e.g. for an i386
Linux emulation the following directories would exist and follow
the filesystem layout conventions of the emulated environment:
/emul/i386-linux/lib
/emul/i386-linux/usr/lib
5. Summary:
We propose the following for 64-bit platforms:
Preferred format of libraries, this is the format used for /lib:
Sparc64: ILP32
x86-64: ILP32
PPC64: ILP32
s390x: ILP32
MIPS64: ILP32
Alpha: LP64
ia64: LP64
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
Reply to: