Date: Thu, 1 Apr 2004 10:16:25 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: "Jacques A. Vidrine" <nectar@FreeBSD.org> Cc: Oliver Eikemeier <eikemeier@fillmore-labs.com> Subject: Re: nss_ldap broken Message-ID: <Pine.GSO.4.10.10404011008290.25682-100000@pcnet5.pcnet.com> In-Reply-To: <20040401143627.GA60225@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10404011008290.25682-100000>