Re: biarch cooperation.
Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Goswin von Brederlow wrote:
> [snip]
> > I worked on dpkg the last days and I modified it to allow packages
> > with the same name but different arch. Making the update transparent
> > and backward compatible needs some more work but overall it seems to
> > be working.
>
> First of all, I'd prefer "Multi-ABI" over "bi-arch" as the name
> of this beast, because
>
> a) There may be more than two ABIs to support.
> b) It is an ABI thing, at least MIPS can run three different
> ABIs on many commonly used CPUs, which share the same Architecture.
Its also an arch thing. i386/486/586/686 all use ia32 abi (i386 with
i486 emulation). apt/dpkg should upgrade to a more optmized arch when
a package becomes available too.
For amd64 its muti-arch / multi-abi.
> (Unfortunately, MIPS CPU families are also sometimes called "architecture".)
>
> > The idea is as wollows: (names made to fit mips but I'm on amd64)
> >
> > - autoconf defaults to lib, lib32, lib64 depending on the host/target
> > used
>
> This won't work well for MIPS. Targets are mips*-*-linux* and
> mips64*-*-linux*, the latter will usually support all three ABIs.
Something would be default for each. For mips that probably /lib, for
amd64 its /lib64.
> > - libraries and -dev packages set "Abi: strict" in the control file
> > (dpkg-gencontrol, dpkg-deb or lintian will check for failure to do
> > so in the future)
> > - dpkg-gencontrol (will) set "Architecture: mips | mips32 | mips64"
>
> Let this better refer to the ABI, like mips or mips_o32, mips_n32, mips_n64.
> There is already too much confusion around the different mips* names:
Architecture describes the hardware you need to run this. Am I right
that mips_o32 works on 32 bit mips and the others need a 64bit mips?
The packages would end up in different binary-<arch> ordners and apt
would use the once the current hardware can run and mix them freely s
long as abi restrictions allow.
> - MIPS I, MIPS II, ... MIPS 64R2 in uppercase refer to the ISA
> (Instruction Set Architecture). The 64 bit capable ISA's are MIPS III,
> MIPS IV MIPS64, MIPS 64R2. The non-64 bit capable ISA's are MIPS I,
> MIPS II, MIPS 32, MIPS 32R2.
> - mips64 refers to some 64 bit aspect, depending on the context, e.g.
> mips64-linux is the GNU target for a toolchain which supports all
> three ABI's mentioned above.
> - ABI N32 runs only on 64 bit capable architectures, mips32 would be
> a gross misnomer.
You have to sort out what you call arch and what abi. I sugget only
splitting arch for things that need different hardware, i.e. 32 bit
and 64bit capable mips.
> > depending on host/target
>
> N32 is a space-optimized variant of N64. It has slightly better performance
> than N64 but is restricted to 32 bit addressing. It is IMHO the preferrable
> ABI on a MIPS Multi-ABI system. N64 is for good for 64 bit Addressing, O32
> will provide backward compatibility.
>
> > - dpkg will match ABIs for packages with "Abi: strict" to match the
> > reverse depends
> >
> > The system will end up with multiple libc6 packages instaled, one for
> > each subarch.
>
> Again, ABI is IMHO a better term. "Subarch" usually describes different
> machine architectures sharing same/similiar CPUs.
Its coined by the iX86 + amd64 series. Might not translate well to
other archs. But Abi doesn't quite cover it either.
> > Using the name package names for each subarch ensures
> > the Depends/Build-Depends/Conlicts/Replaces fields still work.
> >
> > So much for dpkg. Apt will need to know about this next.
> >
> >
> > For the biarch gcc/g++ the gcc-defaults package for amd64, sparc and
> > s390 contain wrapper binaries that set the -m64/-m32/-m31 switch
> > correctly depending on the comandline and uname. Adding th4e same for
> > mips should be easy.
>
> Well, MIPS seems to be a bit special. :-)
>
> ABI is selected via -mabi=32/-mabi=n32/-mabi=64.
> uname is "MIPS" for mips/mipsel, and "MIPS64" for a 64bit capable kernel.
>
> It's probably best to use -mabi=n32 on a "MIPS64" system as default,
> with exceptions for libraries, which should provide all three ABI
> variants somehow, and exceptions for (very) large applications, which
> are of little use in a 32 bit address space (and thus need -mabi=64).
The problem with not using the arch to reflect those is that the
debian archive allows only one version per architecture. You would
have to name the packages differently which we want to avoid.
If you want to have all three abis installable seperately you would
need three archs.
If you can live with a little bloat you can put abi=n32 and abi=64
libs together into the mips64 arch for all essential packages and only
one for other libs.
All that of cause assuming the current binary-<arch> and
<package>-<version>_<arch>.deb structure is kept.
> Thiemo
MfG
Goswin
Reply to: