Re: biarch cooperation.

[Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>]

Goswin von Brederlow wrote:
[snip]
> > Then an i686 package will claim to support ia32 ABI, but it will
> > fail on an i486 CPU, which claims to provide an ia32 ABI.
> 
> No, it will be uninstallable since i686 is not a compatible
> architecture for i486. Architecture is checked first. Abi only when
> required (like libs).
>  
> > Your definition of ABI will provide different Application Binary
> > Interfaces under the same name.
> 
> ABI is only meaningfull when linking. That means libs, -dev, -dbg,
> -pic packages. Installability of a package on its own comes first, abi
> only when dealing with depends between packages.
> 
> Thats how we see it currently.

That's a very debian-specific point of view.

[snip]
> > N32/N64 are way too different for a common label. Btw, there can also
> > be ABI Variants (or subarchitectures, as you call it) for mips:
> > 
> > MIPS I, MIPS II, MIPS III, MIPS IV, MIPS 64, MIPS 64R2
> >                  MIPS 32, MIPS 32R2
> > 
> > which aren't in a simple upward compatible chain (MIPS 32* is the
> > odd one out). Further there are Application Specific Extensions (ASE)
> > like MIPS 16, MDMX, MIPS 3D; similiar to MMX and SSE on ia32.
> 
> Do you realy want to support any of those with a wider range of
> packages?

Probably, depending on demand and the actual performance gain.

> If its just 2-20 packages its better to build them multiple
> flavoured libs into one package and let ld choose the right one, like
> the MMX optimized libs on i386.

E.g. MIPS 16 allow very compact code, on low memory systems that's
interesting for many packages.


Thiemo