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

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

> > - 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
the FHS:

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

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
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Reply to: