Date: Tue, 08 Jun 2004 13:57:16 -0400 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Sean McNeil <sean@mcneil.com> Subject: Re: weak implementation of threads has problems - kse fix attached Message-ID: <1086717435.68846.9.camel@shumai.marcuscom.com> In-Reply-To: <20040608154510.GB89198@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> <Pine.GSO.4.10.10406080028070.11500-100000@pcnet5.pcnet.com> <20040608044844.GA89198@dan.emsphone.com> <20040608072706.GA82243@xor.obsecurity.org> <20040608154510.GB89198@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-FnZVoL0BYwSU0eYirIzC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 11:45, Dan Nelson wrote: > In the last episode (Jun 08), Kris Kennaway said: > > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > > In the last episode (Jun 08), Daniel Eischen said: > > > > No, I don't want to litter all our thread libraries with strong > > > > references. As I've said before, build your shared libraries > > > > correctly so they don't bring in the threads library. > > >=20 > > > A good addition to bsd.port.mk, right next to the "possible network > > > server" etc checks, might be to run ldd on all installed shared > > > libraries and print a warning if any threads libraries show up. Ther= e > > > are a huge number of ports that install shlibs linked to libpthreads. > >=20 > > Some of these are probably correct, in that the library started using > > libpthreads internally and there are a large number of clients that > > would otherwise need to be changed to link to that library. >=20 > I don't think you can have it both ways, though. The rule is either > "pthreads-using shared libraries should pull in a pthreads lib > themselves" or "programs wanting to link to pthreads-using shared > libraries should link with a pthreads lib". >=20 > Attached are patches to add this check to the security-check target.=20 > Ideally they would be checked separately or flagged as something other > than security problems, but that would require copying > security-check.awk and a larger diff.. If we switched PTHREAD_LIBS to -pthread, we wouldn't need this. Shared objects would not have a link to libpthread, and shared objects that really referenced pthread symbols would still require executables to be linked to PTHREAD_LIBS (i.e. how it works on 4.X). Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-FnZVoL0BYwSU0eYirIzC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxf37b2iPiv4Uz4cRAmjEAJ9eZKBGVjPP0j7K+IPemwL49iNo7gCfVmGb 7LWrJiKxUkm7wAmN+o44+A0= =fnCz -----END PGP SIGNATURE----- --=-FnZVoL0BYwSU0eYirIzC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086717435.68846.9.camel>