[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



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: