Re: biarch cooperation.
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.
(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.
> - 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:
- 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.
> 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.
> 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).
Thiemo
Reply to: