> 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 `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
