What does ld.so do that dlopen don't do when loading shared libraries

Ondřej Bílka neleai@seznam.cz
Sun Apr 28 21:35:00 GMT 2013


On Sun, Apr 28, 2013 at 11:08:26PM +0200, Celelibi wrote:
> Hello there,
> 
> This is my first message to this mailing list. ^^
> 
> And I have a question that may be quite unusual: What does ld.so do
> that dlopen don't do when loading shared libraries?
> 
> A bit of explanation may be needed. There is a profiler named TAU
> <tau.uoregon.edu> which can instrument files it compiles and then
> generate a file profile.0.0.0 when the program is run. Much like
> compiling with gcc -pg.
>
Hi,

Did you tried to ask at tau mailing list/forum? Here I could give only
generic advice. 

> And I can do things like: compile a shared library with tau_cc (which
> instrument the shared object) and then link it with a simple program.
> tau_cc.sh -shared -fPIC -o foo.so foo.c
> gcc -o sep sep.c foo.so
> 
> This works fine, running ./sep produce the profile trace. (That
> wouldn't work with gprof.)
> 
> However, if I dlopen/dlsym the library instead of linking against it,
> it doesn't produce any file.
> tau_cc.sh -shared -fPIC -o foo.so foo.c
> gcc -o dyn dyn.c
> 
> 
> Therefore I guess ld.so does something special when it loads the
> needed library that dlopen doesn't do. I think about ctor/entrypoint
> execution, but I have no clue to find out.
>
Library constructors and destructors are run by dlopen so problem is
probably somewhere else.

> I join foo.c sep.c and dyn.c as an example.
> I can also provide the generated binaries if requested.
> 
Did you tried to look if there is something interesting in objdump foo.so?

> 
> PS: I really can't link against the library since the whole
> application is designed as components. All the main program does is
> loading and running .so following a given xml file.
> 
> 
> Best regards,
> Celelibi




More information about the Libc-help mailing list