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
linker.
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:
unstable
--------
fakechroot
fakeroot
ia32-libs
ia32-libs-dev
lib32g2c0
lib32gcc1
lib32gfortran0
lib32objc1
lib32stdc++6
lib32stdc++6-4.0-dbg
lib32z1
lib32z1-dev
libg2c0-dev
libgfortran0-dev
nvidia-glx-ia32
stable
------
ia32-libs
ia32-libs-dev
lib32gcc1
lib32stdc++6
nvidia-glx-ia32
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: