more symbol binding problems

[Sean McNeil]

On Sun, 2004-06-06 at 20:56, Daniel Eischen wrote:
> On Sun, 6 Jun 2004, Sean McNeil wrote:
> 
> > 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)
> 
> You really want to look at the executable (httpd?) too.  What
> does 'ldd' on it show?

Hmmm...

/usr/local/sbin/httpd:
        libz.so.2 => /lib/libz.so.2 (0x200675000)
        libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200784000)
        libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x2008be000)
        libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9
(0x200b12000)
        libldap.so.2 => /usr/local/lib/libldap.so.2 (0x200c28000)
        liblber.so.2 => /usr/local/lib/liblber.so.2 (0x200d60000)
        libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x200e6e000)
        libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x20102b000)
        libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9
(0x20114e000)
        libm.so.2 => /lib/libm.so.2 (0x201270000)
        libcrypt.so.2 => /lib/libcrypt.so.2 (0x201391000)
        libc.so.5 => /lib/libc.so.5 (0x2014ab000)
        libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2016a9000)

So it looks like it is pulling in the ldap library without
pthreads/libc_r first.  So I think what is happening is that the symbols
resolved with ldap aren't updated when it is part of the DAG of php4. 
Not sure why these would get resolved so early.  I should think they are
lazy and happen a lot later.  But perhaps that is the bug?  Are lazy
resolutions failing to take into account the threading library needs
from dlopen'ing php4?