On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote:

Many years ago, I was involved with pthreads for Linux. I helped them get things straight using the weak reference trick. I don't remember where I picked it up from, but I it was real slick how they were used to override functions in libc by having stronger references in the threading lib. libc_r and folks don't use this trick anymore? Odd.

But the questions for today:

Say you have an application that depends on libraries A, B, C, and libc. It then uses dlopen to load D. D depends on E, F, libpthread, and B. Is B considered to be in D's DAG?

If so, then when a function within B calls a function that hasn't been bound yet in libpthread then it should bind to the threaded version. There are good arguments either way. IMHO, rtld is acting as though the answer is no and I want it to behave as yes.

There is strong evidence to support this. The libreadline trace from bash and the php4 trace from httpd both only make sense if the lazy symbol resolver is not ending up with the threaded version of some call (sigaction and select respectively).

Second, to save me some time can someone outline the symbol name mechanism used by libpthread? Here is what I expect:

libc provides a sigaction function through a weak reference that points to some internal name (like __sigaction). libpthread provides a strong reference to sigaction thus, when loaded, overrides usage of sigaction. This should happen irregardless of whether libpthread is in the DAG for the caller (IMHO), but I'm sure there are other opinions.