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

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 Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de

Reply to: