Date: Thu, 1 Apr 2004 08:20:27 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: Sean McNeil <sean@mcneil.com> Subject: Re: nss_ldap broken Message-ID: <Pine.GSO.4.10.10404010804250.29968-100000@pcnet5.pcnet.com> In-Reply-To: <406BE5A2.8020106@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10404010804250.29968-100000>