From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 06:04:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD8D416A4CE; Thu, 1 Apr 2004 06:04:58 -0800 (PST) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.0.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E69543D2D; Thu, 1 Apr 2004 06:04:58 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-49-130.reverse.qsc.de [212.202.49.130]) (authenticated bits=0)i31E4tMG016856 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 1 Apr 2004 16:04:55 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.31; FreeBSD) id 1B92oE-0002bj-Gx; Thu, 01 Apr 2004 16:04:55 +0200 Message-ID: <406C217A.8080102@fillmore-labs.com> Date: Thu, 01 Apr 2004 16:04:42 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: "Jacques A. Vidrine" cc: freebsd-current@FreeBSD.org cc: Sean McNeil Subject: Re: nss_ldap broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2004 14:04:58 -0000 Daniel Eischen wrote: > On Thu, 1 Apr 2004, Oliver Eikemeier wrote: [...] >>- it should be documented somewhere (bsd.port.mk gives you only PTHREAD_LIBS) As far as I understand the problem, every application that doesn't link to pthreads, but uses a library that does crashes on -CURRENT. Am I right there? >>- it requires some major surgery to ports makefiles to make sure that >> libraries and application in a port are linked differently > > I think if you use -pthread instead of -lpthread, it will not > link to the threads library when building a shared library. > Unfortunately, Linux and others seem to have changed their > -pthread behavior so that it no longer avoids linking to > the threads library when building shared. So -pthread may > work for us now, but we may want [be forced] to change. See my answer in the last paragraph. >>- there should be some easy tests, i.e. is it always an error if ldd *.so >> contains libpthread? > > I think it is dependent on the library. If the library truly is > creating threads behind the scene (suppose there were a libaio) > then it needs the threads library. > > On the other hand, for applications that want to use libaio, you > could force them to link to a threads library instead of having > it automatically brought in by libaio. I guess the latter approach will be preferrable, especially since the former does seem to trigger the problem we have... >>I committed a workaround for the OpenLDAP client port, but it seems that we >>have may this problem in other parts of the system too, so a general >>guideline (perhaps with a note in /usr/ports/CHANGES) would be appreciated. >>Or do I overestimate the extend of this issue here? > > I would suspect that most libraries don't create threads on > their own, but it would require maintainers to know a little > more about their ports. I'm not sure there's one easy solution, > but I suppose you could try rebuilding ports with > PTHREAD_LIBS=-pthread to see if that helps and what it > breaks. We can change the default for all ports, and it is (more or less) easy to override the flags in one port, if it uses the wrong ones. I think it is not really feasable to change ports so that libraries and applications are linked with different flags. Currently I returned to accepting the default OpenLDAPs configure gives me, which is -pthread. This is *not* what bsd.port.mk has (-lpthread). What would be the consequences of changing the default back to -pthread? -Oliver