more symbol binding problems

Daniel Eischen eischen at
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?
> Hmmm...
> /usr/local/sbin/httpd:
> => /lib/ (0x200675000)
> => /usr/local/lib/ (0x200784000)
> => /usr/local/lib/ (0x2008be000)
> => /usr/local/lib/apache2/
> (0x200b12000)
> => /usr/local/lib/ (0x200c28000)
> => /usr/local/lib/ (0x200d60000)
> => /usr/local/lib/ (0x200e6e000)
> => /usr/local/lib/ (0x20102b000)
> => /usr/local/lib/apache2/
> (0x20114e000)
> => /lib/ (0x201270000)
> => /lib/ (0x201391000)
> => /lib/ (0x2014ab000)
> => /usr/local/lib/ (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
work correctly.

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.

Dan Eischen

More information about the freebsd-amd64 mailing list