Re: PROPOSED: 32/64 bit coexistence
Vulture <t.sippel-dau@ic.ac.uk> writes:
> 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.
And this proposals defines the qualifiers. Therefore the proposal is
a refinement or enhancement of the FHS.
[...]
>> 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.
The point is that e.g. PPC64 will have 32-bit and 64-bit userland,
/lib will have the 32-bit userland, the 64-bit will go into /lib64
(and corresponding /usr/lib{64}).
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
Reply to: