Re: biarch cooperation.
Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Goswin von Brederlow wrote:
> [snip]
> > > > Package are requested by (sub)arch. Some of those subarchs (like i386,
> > > > i486, i586, i686) have the same abi.
> > >
> > > I still don't like this terminology. An ABI defines a binary
> > > compatibility platform, and i386 vs. i686 aren't compatible, unless
> > > restricted to the least common denomiator.
> >
> > The ABI is compatible both ways,
>
> 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.
> > the architecture only one way.
>
> Which means a i386 CPU with the emulation patches provides a
> i486 "architecture".
>
> Those terms are both grossly misnamed, and are usually used with
> a different meaning.
C++ uses a different abi on i386 and i486+. To run any C++ stuff (like
apt) on i386 you need to emulate a dew instructions i386 doesn't
have. Thats just gcc/g++ screwups and not realy relevant given i386
cpus age. How wants to use a i386 nowadays anyway?
> [snip]
> > > > When you have apache/i686 you look for libfoo. First you find
> > > > "libfoo/amd64", but that only provides the amd64 abi so you discard
> > > > it. Next one would be libfoo/i686, then 586, .... Any of those have
> > > > ia32 abi and would suffice for the depends.
> > >
> > > What will be done in the case of apache/i486? How do you prevent
> > > it from trying libfoo/i686?
> >
> > No. Only sytems capable of running i686 code would have
> > "binary-i686/Packages" (and thus packages for i686) in their search
> > path.
>
> So an in686 try to find a package from "binary-i{3,4,5,6}86/Packages",
> in descending order?
>
> And the package files would be "<pkgname>_<version>_i{3,4,5,6}86.deb"
> (if these are fully optimzed packages)?
Yes. For amd64 you have two repositories binary-amd64/Packages and
binary-i386/Packages and you use both. Currently one has to tell apt
to use both but in the future apt will try all compatible (lower) ones
automatically.
When and how to report missing binary-foo/Packages files remains to be
solved.
> [snip]
> > > I don't see why MIPS would be an exception. Why not always "Strict-Abi: yes"?
> >
> > If there is "Architecture: mips64" with "Abi: n32" or "Abi: n64" that
> > would be a small problem.
>
> 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? 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.
> > But currently binary-<arch> would have to be used to seperate
> > different abis too, so that would make "Architecture: mips_n32" and
> > "Architecture: mips_n64" with respective abis.
>
> "mipsn32" and "mipsn64", I guess. It looks a bit odd, but any
> non-alnum character may break some tools.
>
> > Its the mips guys choice though. You figure out what you want/need/can
> > patch. Having 3 archs is easiest even if it sounds off.
>
> I don't think its off.
>
>
> Thiemo
Sounds odd is what I ment. :)
MfG
Goswin
Reply to: