more symbol binding problems

[Sean McNeil]

On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote:
> On Sun, 6 Jun 2004, Sean McNeil wrote:
> 
> > I have another one that I can't explain.  apache2 and libphp4.
> > 
> > The php4 shared library that is pulled into apache2 has the following
> > (with pthread mapped to libc_r):
> > 
> > /usr/local/libexec/apache2/libphp4.so:
>   [ ... ]
> >         libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000)
> >         libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000)
> >         libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000)
> >         libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000)
> >         libc.so.5 => /lib/libc.so.5 (0x20062a000)
> > 
> > When I use the ldap account manager package (lam), it causes the httpd
> > process to get stuck in a busy-loop eating 1/2 the cpu as:
> > 
> > (gdb) bt
> > #0  0x00000002014fcd4e in select () from /lib/libc.so.5
> > #1  0x0000000200c4532e in ldap_int_select (ld=0x8c8c00, timeout=0x0)
> >     at os-ip.c:733
> > 
> > I do not understand why it is calling select in lib.so.5.  Shouldn't it
> > have called the one in libc_r?  With GLOBAL or LOCAL DAG this should
> > have been resolved via the weak symbol to __select, no?
> 
> Yes, it shouldn't be using select() from libc; select() should be
> resolved to _select() in libc_r (which calls __sys_poll() in libc).
> 
> > The interesting thing here is that if I use libpthread for apache then
> > there are no problems.  Maybe not all that suprising, though, as there
> > is no real difference in the select with libpthread whereas libc_r has a
> > much more complex implementation.
> 
> Sounds like the linker isn't doing the right thing.

Would you think it is the linker, or rtld?  Any ideas where I should
start?  I was going to look through rtld but I will focus on ld if you
think that is where the problem is.