Bug#274367: glibc: [amd64] New GLIBC pass to create 32bit libc6-i386 and libc6-dev-i386 packages
Hi,
I have looked at your patch, I had to tweak it a little as the glibc
version is now 2.3.6. Please find my ver
sion attached. Here are the main changes:
- Make libc6-i386 and libc6-dev-i686 respectively conflicts with the
current version ia32-libs and ia32-libs-dev
- Build-depends on libc6-dev-i686 | ia32-libs-dev (<= 1.5), as a 32-bit
version of the library is necessary to build the tests in the
configure script
- Move .so files from libc6-i686 to libc6-dev-i686
- Some .a files are not necessary, don't ship them
- Don't ship /emul/ia32-linux/usr/bin files, I don't think we need them
- Remove debian/patches/arch-fixup-attribute.dpatch (fixed upstream)
- Fixed the arguments passed to the configure script
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?
- 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?
- 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?
Bye,
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: