Excerpts from Sven Joachim's message of Wed Aug 03 13:58:50 +0200 2011: > On 2011-08-03 13:11 +0200, Michal Suchanek wrote: > > > Excerpts from Jonathan Nieder's message of Wed Aug 03 12:54:12 +0200 2011: > >> Michal Suchanek wrote: > >> > >> > It's possible to take some random binary which is likely to be native > >> > (eg. /bin/sh), run ldd on it, and parse the output to determine what > >> > libc is actually used. > >> > >> But that's the point. Which libc is used depends on the binary. > >> /bin/sh might be an i386 binary and /bin/ls be amd64. How does > >> update-initramfs cope with that? > > > > Currently all libraries are installed in /lib in initramfs so there > > should be only one flavour of binaries (i386 or amd64). > > That seems to be wrong: > > ,---- > | $ lsinitramfs /boot/initrd.img-$(uname -r) | grep -c $(dpkg-architecture > -qDEB_HOST_MULTIARCH) > | 9 > `----
Yes, libraries are installed in the place where they are looked up by ldd so long as they are located automatically by ldd and not copied manually. You can find gems such as these which will break once more libraries get multiarch locations: chroot/usr/share/initramfs-tools/hooks/plymouth: copy_exec /usr/lib/pango/1.6.0/modules/pango-basic-fc.so chroot/usr/share/initramfs-tools/hooks/plymouth: copy_exec /usr/lib/libpango-1.0.so.0 As pango is used by many applications which are used as 32bit binaries it is a likely candidate. > > > On current system there is some main subarch and perhaps a few binaries > > of another subarch which are second grade citizens at best with very few > > libraries to support their installation. > > > > Is that going to change to the point that the essential binaries > > installed in initramfs are going to be a mix of architectures or is > > there still going to be main architecture in the future? > > Most systems will probably not need binaries from foreign architectures, > but they should already work if you can execute them at all. So long as you can find them during initramfs creation and pack them into the initramfs, yes. > > > If the latter then dpkg can show what the main architecture is and only > > binaries from packages of that architecture should be allowed in > > initramfs. If the former then initramfs-tools need multiarch support. > > The copy_exec function that installs a binary into the initramfs runs > ldd and installs the libraries that ldd reports. Don't you think this > is sufficient? Not for NSS modules which are loaded dynamically by libc and not reported as dependencies by ldd. The same applies to the pango modules I would expect. Thanks Michal -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
