This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: What does ld.so do that dlopen don't do when loading shared libraries
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Celelibi <celelibi at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Sun, 28 Apr 2013 23:34:19 +0200
- Subject: Re: What does ld.so do that dlopen don't do when loading shared libraries
- References: <CAJR2zJ-DZ+G-FZw_2SSTPjF-BVkEkmfO9EcSfbUjTa_xKbMcfg at mail dot gmail dot com>
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