I can reproduce this, with both 2.3.6-11 and 2.3.6-12, on i386. Apparently, libc.so.6 is now linked with libgcc_s.so.1 on i386, which was not previously the case with version -9.
Version -9:
[EMAIL PROTECTED]:~>ldd /lib/libc.so.6
/lib/ld-linux.so.2 (0xa7feb000)
linux-gate.so.1 => (0xffffe000)
Version -11:
[EMAIL PROTECTED]:~/src/d-i/installer/build/tmp/netboot_2.6/tree>ldd
/lib/libc.so.6
/lib/ld-linux.so.2 (0x40000000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40029000)
Version -12 udeb, manually unpacked into a d-i tree:
[EMAIL PROTECTED]:~/src/d-i/installer/build/tmp/netboot_2.6/tree>ldd
lib/libc.so.6
/lib/ld-linux.so.2 (0xa7feb000)
linux-gate.so.1 => (0xffffe000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xa7fc9000)
[EMAIL PROTECTED]:~/src/d-i/installer/build/tmp/netboot_2.6/tree>sudo chroot .
bin/sh
bin/sh: error while loading shared libraries: libgcc_s.so.1: cannot open
shared object file: No such file or directory
(Version -11 udeb behaves the same as this.)
<doko> there should be no libgcc dependency in glibc in the first place
<infinity> doko: Well, this had also occurred to me.
<joeyh> I'm not sure where it came from all of a sudden.
<joeyh> did it get built with a new gcc in -11?
<infinity> Maybe it was a side effect of building with -Os.
<infinity> Which has been reverted in -12
<joeyh> -12 also has the problem
We can work around this by upgrading all the d-i build systems to use
the new libc so that library reduction pulls in libgcc, but if this
dependency was only added by accident, I hope it can be removed (40k
more in the d-i image size *hurts*, so do all the daily builds breaking,
so does glibc being blocked from testing until the next d-i beta release
(since this incompatability would break d-i beta 2 if it got in)).
--
see shy jo
signature.asc
Description: Digital signature
