I'd like to know what exactly ldd does. Does it print only libraries from DT_NEEDED structures of .dynamic section? This is not a complete list of libraries that are required to resolve all undefined symbols of ldd's input library, as far as I know. In this case, what is the use of ldd at all?
Or does it really list all the libraries the ldd's input library actually depends on?
This is not a question about whether ldd shows dependencies of dependencies - this is a question about whether libraries reported by ldd resolve all the undefined symbols of ldd's input library.
Does
lddprint only libraries fromDT_NEEDEDstructures of.dynamicsection?
No, that is what readelf --dynamic does.
what is the use of
lddat all?
ldd shows what libraries the runtime linker ld.so loads when starting your executable or loading a shared library. This is a recursive process, e.g. an executable needs a shared library (DT_NEEDED), so that library gets loaded. Then it proceeds to load the dependencies of the loaded library (DT_NEEDED) and so on.
You don't necessarily need ldd, you can just set LD_DEBUG=all environment variable to make ld.so print that information and more. See man ld.so for more information.
Each loaded executable or shared library expose their defined exported dynamic symbols as a lookup scope (a hash table). Lookup scopes form a list. When resolving an undefined symbol ld.so walks the lookup scopes and finds the first one that defines the symbol and resolve the symbol reference. If ld.so reaches the end of lookup scopes it reports the symbol as unresolved.
There is no correspondence between the unresolved symbol name and an executable/shared library it is supposed to come from. ld.so loads all shared libraries from DT_NEEDED sections recursively, builds that list of lookup scopes and then looks for unresolved symbols in there.
How To Write Shared Libraries by U. Drepper explains this in full detail.