Date: Wed, 24 Sep 2003 13:11:21 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Dan Nelson <dnelson@allantgroup.com> Cc: Freebsd Current <current@freebsd.org> Subject: Re: Fixing -pthreads (Re: ports and -current) Message-ID: <Pine.NEB.3.96L.1030924131012.67029D-100000@fledge.watson.org> In-Reply-To: <20030924170633.GA30073@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Sep 2003, Dan Nelson wrote: > Does it really matter if you end up linked to multiple threads > libraries? The first library providing a symbol wins, so the other > shlibs just won't get used at all. Libraries linked from the executable > trump libraries linked from libraries, and LD_PRELOAD wins above all. > If one threads library exports a symbol not in the others, I'd call that > an API bug in the first library. > > This should be no different from explicitly linking in dmalloc to > override the malloc functions in libc, for example. One potential downside to the LD_PRELOAD approach is that it will only work for applications that aren't setuid/setgid. While today most of our privileged and credential-munging applications aren't threaded, I'd like to avoid precluding that in the future as much as possible. What mechanism should be used when LD_PRELOAD is being ignored due to issetugid() returning true? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030924131012.67029D-100000>