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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:56 UTC