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