From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 05:20:39 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 2ECD516A5FE; Thu, 1 Apr 2004 05:20:39 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC44B43D2D; Thu, 1 Apr 2004 05:20:38 -0800 (PST) (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 i31DKRtf004312; Thu, 1 Apr 2004 08:20:28 -0500 (EST) Date: Thu, 1 Apr 2004 08:20:27 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Oliver Eikemeier In-Reply-To: <406BE5A2.8020106@fillmore-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 13:20:39 -0000 On Thu, 1 Apr 2004, Oliver Eikemeier wrote: > Sean McNeil wrote: > > On Wed, 2004-03-31 at 13:48, Daniel Eischen wrote: > > > >>On Mon, 29 Mar 2004, Daniel Eischen wrote: > >> > >>Too bad these shared libraries can't be made to use > >>the libgcc trick, so they can still be thread-safe > >>but not depend on a threads library. That would > >>also make it easier to use different thread libraries > >>for different applications relying on common shared > >>libraries. > > > > I'm unclear as to why any library that is thread-safe would need to be > > linked with libpthread.so. Since libc already has the hooks in there, I > > don't see why you need to link with it unless you are actually > > using/relying on threads. IMHO, we should just not link libpthread.so > > into these shared libraries. > > I do understand some of the technical diffuculties here, but: > > - it should be documented somewhere (bsd.port.mk gives you only PTHREAD_LIBS) > > - 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. > - 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 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. -- Dan Eischen