more symbol binding problems

[Sean McNeil]

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:
        libcrypt.so.2 => /lib/libcrypt.so.2 (0x200aed000)
        libmcal.so => /usr/local/lib/libmcal.so (0x200c07000)
        libc-client4.so.8 => /usr/local/lib/libc-client4.so.8
(0x200d18000)
        libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200ee2000)
        libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x20101c000)
        libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x201270000)
        libpq.so.3 => /usr/local/lib/libpq.so.3 (0x201393000)
        libmysqlclient.so.12 =>
/usr/local/lib/mysql/libmysqlclient.so.12 (0x2014b3000)
        libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x2015dc000)
        libmcrypt.so.8 => /usr/local/lib/libmcrypt.so.8 (0x2016f6000)
        libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0x20182f000)
        libldap.so.2 => /usr/local/lib/libldap.so.2 (0x201937000)
        liblber.so.2 => /usr/local/lib/liblber.so.2 (0x201a6f000)
        libpam.so.2 => /usr/lib/libpam.so.2 (0x201b7d000)
        libintl.so.6 => /usr/local/lib/libintl.so.6 (0x201c85000)
        libz.so.2 => /lib/libz.so.2 (0x201d8f000)
        libm.so.2 => /lib/libm.so.2 (0x201e9e000)
        libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x201fbf000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2021db000)
        libodbc.so.1 => /usr/local/lib/libodbc.so.1 (0x2023cb000)
        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
#2  0x0000000200c34459 in wait4msg (ld=0x8c8c00, msgid=1, all=1,
timeout=0x0,
    result=0x7fffffff9c38) at result.c:312
#3  0x0000000200c33fe7 in ldap_result (ld=0x8c8c00, msgid=1, all=1,
    timeout=0x0, result=0x7fffffff9c38) at result.c:113
#4  0x0000000200c376d4 in ldap_extended_operation_s (ld=0x8c8c00,
    reqoid=0x200c55134 "1.3.6.1.4.1.1466.20037", reqdata=0x0,
sctrls=0x0,
    cctrls=0x0, retoidp=0x7fffffff9c90, retdatap=0x7fffffff9c98)
    at extended.c:138
#5  0x0000000200c4f606 in ldap_start_tls_s (ld=0x8c8c00,
serverctrls=0x0,
    clientctrls=0x0) at tls.c:1725
#6  0x0000000203bf7a62 in ?? () from
/usr/local/libexec/apache2/libphp4.so
#7  0x0000000203cbfcd3 in ?? () from
/usr/local/libexec/apache2/libphp4.so
#8  0x0000000203cbfec9 in ?? () from
/usr/local/libexec/apache2/libphp4.so
#9  0x0000000203cb2a8a in ?? () from
/usr/local/libexec/apache2/libphp4.so
#10 0x0000000203c8cbee in ?? () from
/usr/local/libexec/apache2/libphp4.so
#11 0x0000000203cc4ca5 in ?? () from
/usr/local/libexec/apache2/libphp4.so
#12 0x00000000004222ea in ap_run_handler (r=0x7ba090) at config.c:151
#13 0x0000000000422860 in ap_invoke_handler (r=0x7ba090) at config.c:358
#14 0x000000000041f973 in ap_process_request (r=0x7ba090) at
http_request.c:246
#15 0x000000000041b5bc in ap_process_http_connection (c=0x7b21b0)

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?

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.

Cheers,
Sean