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

Celelibi celelibi@gmail.com
Sun Apr 28 22:58:00 GMT 2013

2013/4/28, Ondřej Bílka <neleai@seznam.cz>:
> Did you tried to ask at tau mailing list/forum? Here I could give only
> generic advice.

I did, yes. (Still waiting for an anwser.)
But since it seems to me like a ld.so vs. dlopen issue, I

> Library constructors and destructors are run by dlopen so problem is
> probably somewhere else.

Must be soemthing else then. :(

>> 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?

Yes, I already tortured it a bit. :)
It contains a lot of things... It grew from 6.5Ko to 436Ko. It depends
on a several standard libraries, thought it seems like TAU itself is
statically linked.
It defines a lot of symbols (1143), and have only 177 undefined symbols.
It adds calls to __cyg_profile_func_enter@plt and
__cyg_profile_func_exit@plt at the begining and end of my function(s).
I guess that's how it profiles it.
The code of the entrypoint is not the same with and without TAU
although it seems to do something similar but I cannot gurantee (my
x86_64 is not very fluent).

And... Well, that's pretty much all I can tell. Nothing that could say
"hey, look here, I can't work without this".

More information about the Libc-help mailing list