How do I build a cross-ldd?
Dave Dodge
dododge at dododge.net
Tue Dec 19 19:45:30 PST 2006
On Tue, Dec 19, 2006 at 10:05:27AM -0500, Rob Landley wrote:
> On Tuesday 19 December 2006 3:25 am, Dave Dodge wrote:
> > I think it also tracks down dependencies recursively,
>
> Not that I know of. I had to write a script when I wanted the recursive
> dependencies. (See the busybox test suite.)
This may just be a side-effect of how glibc's ldd is implemented, but
that one does appear to operate recursively. For example in this case
"foo" was originally linked against a self-contained libbar.so.1, but
I have an alternate build of libbar.so.1 (with the same soname) that
internally makes use of libblah.so.1. Changing LD_LIBRARY_PATH causes
the additional library to appear in the ldd output:
$ export LD_LIBRARY_PATH=/tmp/bar1:.
$ ldd ./foo
libbar.so.1 => /tmp/bar1/libbar.so.1 (0x40014000)
libc.so.6 => /lib/libc.so.6 (0x4001c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ export LD_LIBRARY_PATH=/tmp/bar2:.
$ ldd ./foo
libbar.so.1 => /tmp/bar2/libbar.so.1 (0x40014000)
libc.so.6 => /lib/libc.so.6 (0x4001c000)
libblah.so.1 => ./libblah.so.1 (0x4013d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ldd --version
ldd (GNU libc) 2.3.2
I'm pretty sure I've seen this sort of thing in real situations, such
as having multiple builds of an image processing library with
different optional features (e.g. tiff support) configured.
-Dave Dodge
More information about the uClibc
mailing list