Re: weak implementation of threads has problems - kse fix attached

From: Joe Marcus Clarke <marcus_at_marcuscom.com>
Date: Tue, 08 Jun 2004 13:57:16 -0400
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.
> > > 
> > > 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.  There
> > > are a huge number of ports that install shlibs linked to libpthreads.
> > 
> > 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.
> 
> 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".
> 
> Attached are patches to add this check to the security-check target. 
> 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

-- 
PGP Key : http://www.marcuscom.com/pgp.asc

Received on Tue Jun 08 2004 - 15:57:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:56 UTC