Hello, thanks for looking at the patch!
On 06-Feb-09 19:48, Aurelien Jarno wrote: > It seems to work well, at least it produces a usable i386 libc. I have > still a few questions though: > - Contrary to libc6-dev-amd64 on i386, libc6-dev-i686 does not ship any > header file. Is it intentional? Looking at libc6-dev-ppc64, > libc6-dev-sparc64 and at the mips tri-arch support patch, I may revert > the question to: Is it really necessary to ship headers with > libc6-dev-amd64 on i386? I am not really sure about this but at least on powerpc/ppc64 things work fine for me as they are now. > - On plain i386, there is a i686 version of the libc built with > -march=i486 -mtune=i686. As all the x86_64 processors support MMX, SSE > and SSE2 instruction sets. I propose to use -march=pentium4 for > libc6-i386. What do you think? -march=pentium4 should be fine. > - Why the 32-bit version is located to /emul/ia32-linux/ instead of > /lib32 (as it is the case for the mips tri-arch patch)?. Is there any > rational behind that? What does the LSB says? My personal opinion is that /emul/ia32-linux is ugly and (/usr)/lib32 should be used for 32-bit libraries on amd64. The LSB (or more precisely the FHS) is somewhat problematic here. It generally allows the usage of /lib32 for some architectures. However, for amd64 it requires 64-bit libraries to be in /lib64 and 32-bit libraries to be in /lib (!) which is simply not possible in the current Debian setup where /lib64 is a symlink to /lib. Anyway, the /emul/ia32-linux directory is completely unknown to the FHS/LSB. So I think it is much closer to the LSB/FHS to use /lib32 than /emul/ia32-linux. Technically it will also be easier to use /lib32 because this will be automatically in the standard library search paths while /emul/ia32-linux has to be specified explicitly. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
