Bug#295412: initrd-tools: Fails to ignore 32bit emulation layer on ldd calls

[Erik van Konijnenburg <ekonijn@xs4all.nl>]

On Wed, Feb 23, 2005 at 05:58:59AM +0100, Harald Dunkel wrote:
> Joshua Kwan wrote:
> > Harald Dunkel wrote:
> >
> >> Assuming that valid shared library paths start with '/'
> >> I would suggest to apply this patch to mkinitrd:
> >
> >
> > Hmm, maybe not if LD_LIBRARY_PATH is being used. Beware.
> >
> 
> ???
> 
> I am not sure whether searching dynamic libraries
> relative to either the $CWD or to the bin directory
> is a good idea, especially for system tools.

Agreed.  Your proposed patch is certainly much cleaner than grepping
linux-gate away.

If I understand the linux-gate concept correctly, its an area
of memory mapped into application process space not based on
a segment in an object file, but based on a prototype the kernel
provides.  What mkinitrd should recognise is that there's no file
listed that the shared library resolves to.

A pattern such as / =>  \(0x/ should recognise these cases
and still maintain current behaviour with regard to LD_LIBRARY_PATH.

Incidentally, there may be another ldd related bug waiting to happen.
Currently, mkinitrd accepts ldd 2.3.2 output that look like this:

	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)

But in ldd 2.3.3, that output format will change to this
(tested in Fedora FC3):

	/lib/ld-linux.so.2 (0x0056f000)

Perhaps that pattern should also be matched.

Regards,
Erik