PROPOSED: 32/64 bit coexistance

[George Kraft IV <gk4@austin.ibm.com>]

FHS & LSB teams,

IBM and SuSE has the following suggestion regarding 32/64bit coexistance.

George (gk4)

> > 32/64bit executable coexistence
> >
> > 32/64bit executable coexistence on architectures with 32/64bit
> > backward compatibility
> >
> > 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.
> >
> > There is a decision to be made about the location and naming
> > conventions for the dedicated libraries, if backward
> > compatibility of existing 32bit applications on 64bit systems is
> > desired.
> >
> > 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 fully exploit the 64bit architecure;
> > nevertheless they are able to run 32bit code, too.
> >
> > 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:
> >
> > - 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
> >   32bit and 64 bit userland executables.
> >
> > Applications can be build either using 32bit or 64bit and are
> > usually 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.
> > [...]
> >
> > 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 been implemented 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. This is clearly not an issue for the loader, that will
> > be able to properly select the library to load from, but will be an
> > issue for all existing 32bit applications and their install scripts
> > and the like, not knowing about the hybrid nature of a 32/64bit
> > system environment. Thus we're suggesting that /lib is always a
> > symbolic link to /lib32 to grant backward compatibility and new 64bit
> > applications to use and install into /lib64.

-- 
George Kraft IV
gk4@austin.ibm.com