Re: PROPOSED: 32/64 bit coexistence
Andreas Jaeger wrote:
>
> What do you think? Have we reached consensus - or where is still room
> for clarification?
....
> 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.
So far I was with you, but the names lib32 and lib64 are *examples*,
the FHS supports:
/lib<qual> and /usr/lib<qual>
where the list of qualifiers is undefined.
> 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. [...]
The salient word is "might": a very weak "recommendation"
> 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).
A "pure" 64 bit system would surely be ILP64, by definititon an
int in C can be added to a pointer to obtain another pointer of
the same type. LP64 with 32 bit ints would not allow a program
address chars in a memory image of a file over 2 Gigabyte in size -
a DVD movie image, say.
This may not be a problem now, but in time it will be. For example,
if you model air flow through a complete aero engine, 10 to 50
Tb of memory (1 to 6 Terabytes) would certainly come in handy,
and addressing the points in the structure with 32 bit ints becomes
difficult.
> 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)
Fine for the time being, this is a "32 bit systemm with some
64 bit capabilities"
This could run "Legacy 32 bit Applications" (which are linked
against /lib meaning ILP32) and "32 bit Applications" (which
are linked against /*/lib32 meaning ILP32), as well as "small
model ia64 Applications compatible with 32 bit Environments"
(meaning linked against /*/libia64 with ILP32") and "ia64
Applications for 32 bit Compatibility Environments" (meaning
linked against /*/libia64 with LP64).
> * rpm is known to fail on nested symlinks within in pathes
> on updating those directories; therefore /lib should not
> be a link to /lib32.
Rpm could detect such a system by /lib32 being a link to /lib,
by inspecting releasee files etc..
> * 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.
Yes, and they acquire the "Legacy" moniker. To loose that, they
can start linking against /*/lib32 - a 5 minute "porting" effort.
> * 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, ...)
This is true for a few years, same as "640 kilobytes ought to be
enough for anybody", against which we should hold the (updated)
RMS statement: it is OK to use a Gigabyte memory, GNU will probably
not run on 32 bit systems anyway (see GNU coding standard for the
original ;-)
> 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
definitely not. At boot time a processor sort of knows what it is, and
the kernel mounts /, which later mount /usr for the bulky stuff.
What is wrong with /usr/lib/emul/<emulated architecture moniker>/
Then an application can just be linked against libraries in
/usr/lib/emul/ia64 (say) and will run equally well on little-endian
mips as on big-endian sparc machines. The only thing then needed
are the emulators ;-)
> Preferred format of libraries, this is the format used for /lib:
> Sparc64: ILP32
Sparc - with lib32 -> lib: ILP32, with lib64 -> lib: LP64.
just lib: ILP64 (and presumably 16 bit chars and 32 bit shorts)
> x86-64: ILP32
ditto, mutatis mutandis, although AMD may be happy for some time
with 32 bit pointers and longs for the "low cost" market
> PPC64: ILP32
> s390x: ILP32
Does IBM really want to cap its processors at 32 bit longs and pointers ?
For the s390x this is probably OK, as the new stuff is now "zSeries", but
I still would not be sure.
> MIPS64: ILP32
> Alpha: LP64
> ia64: LP64
When Alpha came out in 1993 it was slanted as "with a growth path for 20
years or more", we are now at the half-way stage, and it sort-of seems dead
in the water. But I am sure Intel will for its main processor want a way
to process objects bigger than 2 billion items in size, and that means ILP64.
Remember, Unix was addressing files with 32 bit offsets when a megabyte of
memory got you well past the mega$ computer price. We still use them at a
time when scientific desktops with less than a gigabyte memory are "not
economic to buy". We should look a little forward to a time when 2 gigabyte
memeory modules carry a nuisance penalty the way 20 gigabyte disk drives
do now.
Thomas
* Why not use metric units and get it right first time, every time ?
*
* email: cmaae47 @ imperial.ac.uk
* voice: +4420-7594-6912 (day)
Reply to: