Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Tollef Fog Heen <tfheen@raw.no> writes:

> * Goswin von Brederlow 
> 
> | Tollef Fog Heen <tfheen@raw.no> writes:
> 
> [...]
> 
> | > | > 	*/include/* -> */include64/*
> | > | > 		(header files may be architecture specific)
> | > | 
> | > | Use #ifdef __AMD64__ #elif __I386__ ....
> | > 
> | > eww.  This will be especially fun for asm/ and bits/
> | 
> | Not sure how gcc and libc6 do it currently but they already
> | manage. I'm fine with keeping it that way.
> 
> They manage through manual hacking and doing evil stuff like building
> the lib64c6 on i386 as an i386 package.  The current design just won't
> work, or at least won't be pretty, ever.  I've spent a few weeks
> trying to get gcc and glibc to cooperate.
> 
> If you want to build a gcc with support for generating both 32 bit and
> 64 bit binaries you need a 32 bit libc built with linux-kernel-headers
> from amd64, since else it won't find the correct register names in
> bits/sigcontext.h at least.
> 
> If you think I'm talking out of my ass, feel free to build a new,
> up-to-date biarch 32 bit glibc which works for compiling gcc in biarch
> mode.
> 
> | There are 10K packages in debian main and ~2.5K of those are lib
> | packages, ~0.5K are binary-all. So a full amd64 port would have the
> | existing 20K packages plus ~2K new -common packages. But keep in mind
> | that the splitting of the libs would be done over the next 2 or 4
> | years (1 or 2 releases). Its not like after sarge every maintainer has
> | to jump and split his package.
> 
> I think that if you are increasing the number of packages in Debian by
> 20%, you might have a problem in your design.

The 20% increase happens with or without my design. Thats just
multiarch support if its done for every lib in debian, _if_.

We certainly don't need everything to be 64 bit.

MfG
        Goswin