more symbol binding problems
eischen at vigrid.com
Mon Jun 7 04:37:44 GMT 2004
On Sun, 6 Jun 2004, Sean McNeil wrote:
> On Sun, 2004-06-06 at 20:56, Daniel Eischen wrote:
> > You really want to look at the executable (httpd?) too. What
> > does 'ldd' on it show?
> 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
> 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
> 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?
Libc is the second library on the list, so any attempt to dlopen()
a library that needs libc_r (or even libpthread) isn't going to
I think basically all your problems are the result of things
being linked (ld) improperly. If the executable is going to
dlopen() a library that requires the threads library, then
the executable must explicitly link to the threads libary.
I said before, if you set CFLAGS=-pthread, it will avoid
linking to libpthread when building shared libraries.
More information about the freebsd-amd64