Re: [crosstool-ng] Small question and mini-patch

[Brian Dessent <brian at dessent dot net>]

"Yann E. MORIN" wrote:

> > Now, the question.  Is it just me or does anyone else find a cross-ldd
> > tool to be useful for the host?
> 
> Do you by chance know how to generate one? ;-)

ldd is not so much a tool but a wrapper script that simply sets some
environment variables that glibc recognises.  You can achieve the same
effect by e.g. "LD_TRACE_LOADED_OBJECTS=1 command" and instead of
running 'command', glibc will trace what it would have done; see "man
ld.so".

The problem for a cross environment is obvious: you can't execute the
target-glibc, and even if you could it still wouldn't work because it
would expect to search for native paths and not sysroot-ed paths.

To a first approximation you can achieve the same thing by just listing
the DT_NEEDED tags of the binary, e.g. "$target-objdump -p binary | grep
NEEDED" or "$target-readelf -d binary | grep NEEDED".  This will show
you the immediate first-order dependencies of 'binary', but to replicate
what ldd shows you'd have to then recursively apply the same command to
each listed element to compute the full set.

An additional problem is that the NEEDED tag lists just the SONAME,
without a path.  This method completely lacks emulation of the
complicated path searching logic in the dynamic loader, which has to
take into account all the various ways that shared libraries can be
found:

- LD_LIBRARY_PATH environment variable
- DT_RPATH and DT_RUNPATH dynamic tags
- ld.so.conf
- hard-coded system defaults like /usr/lib

So this means that any kind of cross-ldd would have to replicate all of
this, which would be a non-trivial task, but not one that would be
totally impossible.  But I think for the majority of cases you are
really only interested in the first-order dependencies of a program or
library anyway, so it's not necessary.

Brian

--
For unsubscribe information see http://sourceware.org/lists.html#faq