From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 07:16:56 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 87B5916A4CE; Thu, 1 Apr 2004 07:16:56 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1529E43D2D; Thu, 1 Apr 2004 07:16:56 -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 i31FGPtf003392; Thu, 1 Apr 2004 10:16:25 -0500 (EST) Date: Thu, 1 Apr 2004 10:16:25 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: "Jacques A. Vidrine" In-Reply-To: <20040401143627.GA60225@madman.celabo.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org cc: Sean McNeil cc: Oliver Eikemeier 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 15:16:56 -0000 On Thu, 1 Apr 2004, Jacques A. Vidrine wrote: > On Thu, Apr 01, 2004 at 04:04:42PM +0200, Oliver Eikemeier wrote: > > 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? > > No. Problems only occur if run-time loading/unloading via > dlopen/dlclose is used, and then only if a lock or other thread > library data structure might be held ``across'' the load or unload. > So I think it is a rare, but troublesome, condition. > > When you changed the way OpenLDAP was linked, this condition occurred > within libc due to dynamic loading of nss_ldap. So, lots of people's > working systems suddenly starting crashing after upgrading. > > I was able to work around the problem in libc, because there, we > have the freedom to putz with internals like __isthreaded. Real > applications don't have that luxury. > > [...] > > >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... > > So far no library has been found that does ``the former'' (create > threads behind the scene). > > > It seems to me we need one of a few things to happen to our threads > implementation*s*: > > (a) pthread.h provides all the magic needed to make pthread_* > symbols weak, i.e. transparently providing the functionality of > the `libgcc hack' which Dan says would avoid the problem. I don't think that will work; it'll break applications/libraries not expecting those functions to be NULL. > (b) ``somehow'' arrange for the unloading of a thread library to > fixup the pthread stubs `back to normal'. er, that sounds like > a load of work and dangerous to boot. > > (c) teach rtld to treat thread libraries specially: ignore them during > dlopen even if they are specified in DT_NEEDED. perhaps we could > add some info to the ELF headers of our thread libraries that rtld > could use to implement this. hacky. I think the best way is to avoid having shared libraries needlessly linked to a threads library. -- Dan Eischen