more symbol binding problems

[Daniel Eischen]

On Mon, 7 Jun 2004, Sean McNeil wrote:

> On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote:
> > 
> > It doesn't work here and I don't believe ever has since libc_r
> > was split from libc.
> 
> 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.

I don't know what a DAG is, but I believe I've already explained
the problem.  We don't litter our thread libraries with strong
references for every thread interface.  You must make sure
references are resolved correctly by linking ordering.

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

There are no strong references (other than a handful that are
needed by rtld).  We mandate that you link things in the proper
order.

-- 
Dan Eischen