Bug#274367: glibc: [amd64] New GLIBC pass to create 32bit libc6-i386 and libc6-dev-i386 packages
Hello,
On 06-Feb-10 12:58, Aurelien Jarno wrote:
> > The '--includedir=/usr/include/i386-linux' is also no longer necessary
> > because this is handled automagically by the wrappers in
> > linux-kernel-headers.
>
> This is not the include path of the kernel headers, but the place were
> to install the glibc headers. Look at i386.mk or hppa.mk.
I was thinking about the --with-headers switch, sorry for the confusion.
> Please find attached a new patch, that uses /lib32 and /usr/lib32. There
> is a lot of difference from the previous patch, so don't hesitate to
> comment it. I know there is a missing conflicts with the current version
> of ia32-libs, I am currently looking for a way to do it cleanly.
Thanks for the new patch! I tried to compile glibc with this patch
and the compilation was basically successful. I had to add the missing
debian/control.in/i386 file with the control information for the
libc6-(-dev)-i386 packages.
The resulting libc6-dev-i386 package still has two small problems.
The symlinks in libc6-dev-i386 need to be changed from e.g.
lrwxrwxrwx root/root 0 2006-02-11 08:02:36 /usr/lib32/librt.so -> /lib/librt.so.1
to
lrwxrwxrwx root/root 0 2006-02-11 08:02:36 /usr/lib32/librt.so -> /lib32/librt.so.1
Also, in /usr/lib32/libc.so the line
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
has to be changed to
GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a )
and in /usr/lib32/libpthread.so the line
GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )
has to be changed to
GROUP ( /lib32/libpthread.so.0 /usr/lib32/libpthread_nonshared.a )
Alternatively, something like '--libdir=/usr/lib32' could be added
to the configure options and everything could be installed in
/usr/lib32, i.e. the top-level /lib32 directory could be dropped
entirely.
To have an extra top-level directory /lib32 with 32-bit libraries
does not make much sense anyway. During the boot process
the top-level /lib directory with the native 64-bit libraries
should be sufficient.
However, the packaging process for the libc6-(dev)-i386 packages would
have to be changed a little to take this change into account.
Regards
Andreas Jochens
Reply to: