Bug#274367: glibc: [amd64] New GLIBC pass to create 32bit libc6-i386 and libc6-dev-i386 packages
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
Reply to: