From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 04:37:44 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 448B116A4E2; Mon, 7 Jun 2004 04:37:44 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4E1D43D39; Mon, 7 Jun 2004 04:37:43 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i574bhtD020478; Mon, 7 Jun 2004 00:37:43 -0400 (EDT) Date: Mon, 7 Jun 2004 00:37:43 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086581186.59212.12.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:37:44 -0000 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: > 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? 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