1752675
Members
5830
Online
108789
Solutions
SOLVED
actually its not a "text file busy" issue.
dld is a special shared library which (as you may know) actually loads other shared libraries required by the program.
the ldd functionality is actually implemented inside dld itself. when you run ldd on an executable file, ldd actually invokes your executable with _HP_DLDOPTS set to "-ldd". the dld loads all the shared libraries and on seeing "-ldd" in _HP_DLDOPTS, lists them out (but does not transfer control to the program, so the program does not run).
when you run ldd on a shared library, a dummy program /usr/ccs/bin/lddstub is invoked with the specified library effectively preloaded and with _HP_DLDOPTS set to "-ldd". so about the same thing as above happens.
if you try this with dld.sl, the dld which is already loaded tries to load itself again and fails (i guess you cant mmap same file shared twice in the same process?). this is what you see as a "failure".
ldd is not written to handle this special case and will probably not be fixed either : it is not really worth the effort because anyway, there isnt really much you can find by running ldd on dld.sl: it does not depend on any other shared libraries and all its symbol references are resolved internally (by itself of course, on startup, amounting to immediate binding).
--
ranga
[i work for hpe]
dld is a special shared library which (as you may know) actually loads other shared libraries required by the program.
the ldd functionality is actually implemented inside dld itself. when you run ldd on an executable file, ldd actually invokes your executable with _HP_DLDOPTS set to "-ldd". the dld loads all the shared libraries and on seeing "-ldd" in _HP_DLDOPTS, lists them out (but does not transfer control to the program, so the program does not run).
when you run ldd on a shared library, a dummy program /usr/ccs/bin/lddstub is invoked with the specified library effectively preloaded and with _HP_DLDOPTS set to "-ldd". so about the same thing as above happens.
if you try this with dld.sl, the dld which is already loaded tries to load itself again and fails (i guess you cant mmap same file shared twice in the same process?). this is what you see as a "failure".
ldd is not written to handle this special case and will probably not be fixed either : it is not really worth the effort because anyway, there isnt really much you can find by running ldd on dld.sl: it does not depend on any other shared libraries and all its symbol references are resolved internally (by itself of course, on startup, amounting to immediate binding).
--
ranga
[i work for hpe]
