Bug#274367: glibc: [amd64] New GLIBC pass to create 32bit libc6-i386 and libc6-dev-i386 packages
> 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.
I have looked at this part a little more, and it seems libc6-dev-i686
has to provide i386 headers as they are different than the amd64 one.
This is not the case for ppc64 and sparc64 are they are a subarch of ppc
and sparc, whereas amd64 and i386 are different archs.
I have modified that in my version of the patch, I am currently doing a
> > - 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.
Also added to my version of the patch.
> > - 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.
It looks like this library has been choosed because it is the library
used by ia32-libs, which was ia64 specific before. Note the rationale of
"IA-64 uses a different scheme, reflecting the deprecation of 32-bit
binaries (and hence libraries) on that architecture."
> 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
It looks like in case of ia64 this directory is handled directly into
the kernel. On amd64, this ugly (IMHO) path has to be handled by the
I also think it would be better, also because it could be handle easily
by the current build scripts of the glibc. However, the change seems
difficult as a lot of libraries is already using it:
However, waiting some more will make it more difficult. I think this has
to be discuss widely. Maybe debian-devel ?
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' firstname.lastname@example.org | email@example.com
`- people.debian.org/~aurel32 | www.aurel32.net