[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

* 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

| 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.

Tollef Fog Heen                                                        ,''`.
UNIX is user friendly, it's just picky about who its friends are      : :' :
                                                                      `. `' 

Reply to: