[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?


     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

   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

   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

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:


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

Reply to: