Bug#279382: 64-bit kernel -> ldd -> mkinitrd issue

[Barak Pearlmutter <barak@cs.may.ie>]

Package: initrd-tools
Version: 0.1.74

There is an unfortunate interaction that occurs when a system is
running an em64t-p4 or amd64 kernel, but a standard 32-bit "testing"
user space.  When configuring a kernel-image package the mkinitrd
fails with a cpio failure to read a file named "(0x00000000)".

The cause of this is that "ldd" has an extra entry: with a 32-bit
kernel you see this

    # ldd /bin/cat

		    libc.so.6 => /lib/tls/libc.so.6 (0x40028000)
	    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

but with a 64-bit kernel you see this

    # uname -a

    Linux x 2.6.8-9-em64t-p4-smp #1 SMP Thu Oct 7 16:01:47 CEST 2004 x86_64 GNU/Linux

    # ldd /bin/cat

	    linux-gate.so.1 =>  (0x00000000)
	    libc.so.6 => /lib/tls/libc.so.6 (0x5557d000)
	    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000)

When mkinitrd runs ldd on executables to find libraries to be included
them in the initrd, it does not skip the linux-gate line and instead
includes an entry for the strange filename, which fails.

This would be really easy to fix by hacking mkinitrd, either by
ignoring filenames that don't start with "/", or that do start with
"(", or by ignoring the linux-gate lines specially, or whatever.

Or (the "right" solution) ldd could be modified to take a flag telling
it to just print the filenames of all used libraries and mkinitrd
could call it that way, removing the need to parse ldd's output.

But as a cheesy workaround for myself, which might be of value to
others, I created a stub

    # cat /usr/local/bin/ldd

    #! /bin/sh
    /usr/bin/ldd $* | egrep -v linux-gate\[.\]so\[.\]1

and then did

  PATH=/usr/local/bin:$PATH dpkg --configure --pending

which worked fine.
--
Barak A. Pearlmutter <barak@cs.may.ie>
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www-bcl.cs.may.ie/~barak/