Date: Thu, 1 Apr 2004 17:08:51 -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.10404011703200.15557-100000@pcnet5.pcnet.com> In-Reply-To: <20040401215308.GA79924@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 11:42:59AM -0500, Daniel Eischen wrote: > > On Thu, 1 Apr 2004, Jacques A. Vidrine wrote: > > > > > On Thu, Apr 01, 2004 at 10:16:25AM -0500, Daniel Eischen wrote: > > > > I think the best way is to avoid having shared libraries needlessly linked to > > > > a threads library. > > > > > > If we can guarantee that -pthread would give that behavior ``forever'', > > > then great. I guess we've come full circle (``-pthread good'' > > > ``-pthread bad, don't use it'' ``-pthread good''). :-) > > > > > > Then how does one pick an alternate threading library? Say `libmap' and > > > > Override PTHREAD_LIBS to be -lthrlibofchoice for > > the port you are building. > > Then we're back where we started. The port will build its applications > *and* libraries with a DT_NEEDED libthrlibofchoice.so.N. If something > dlopens/dlcloses the library, again we're playing with fire. No, you build the _application_ with -lthrlibofchoice, not libraries. I'm thinking someone might want mozilla with libpthread and mplayer with libthr, but both perhaps use libGL or some other thread-safe library. Sure, there are ports that have both applications and libraries, and who really cares what the applications are linked to. But if you are overriding PTHREAD_LIBS, you don't do it for a port that installs a common library that other threaded applications want to use. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10404011703200.15557-100000>