Re: biarch cooperation.
Guido Guenther <firstname.lastname@example.org> writes:
> On Sun, Dec 14, 2003 at 08:57:39PM -0500, C. Scott Ananian wrote:
> > Perhaps Guido can elaborate further on this? I've been using gcc to
> > generate 64-bit ELF binaries on IRIX, so I'm pretty sure that works well,
> > although its possible that binutils are broken (but for what it's worth,
> > IRIX 64-bit binutils are broken, too -- the system assembler doesn't do
> > label addition properly).
> On mips we actually want to support three ABIs o32 (which goes into /lib
> and which is what we currently support), n32 (/lib32, improved calling
> conventions and floating point performance, 64bit wide register but
> 32bit address space) and n64 (/lib64).
> I've played with n32/n64 and can build statically linked binaries
> easily. I also started to build a dl'ed n32 userspace. The problems
> Gotom mentions are mostly resolved now.
> > More to the point: how can I help this effort on mips64? What/where are
> > the current debian biarch packages (toolchain-source, dpkg-cross, dpkg,
> > apt) so I can hack & submit patches to support mips64.
> We don't have any publically available biarch debian packages yet. I was
> hoping to look into how much our packaging tools support (bi,tri)-arch
> nowadays soon. What is the exact status of this?
> -- Guido
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
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
- 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"
depending on host/target
- dpkg will match ABIs for packages with "Abi: strict" to match the
The system will end up with multiple libc6 packages instaled, one for
each subarch. 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.