more symbol binding problems

[Daniel Eischen]

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.

-- 
Dan Eischen