On Wed, 24 Sep 2003, Scott Long wrote:
> I'm a big advocate of using libmap to deal with this.
Ditto.
Based on the results seen thus far, my preference would really be for:
(1) Keep -pthread, make it imply -lpthread, saving a lot of hassle.
(2) Ship all packages and binaries using threading with -lpthread -- i.e.,
a dynamic library dependency on libpthread. This will mean that
administrators don't have to list each possible threading library in
/etc/libmap.conf in order to be sure they caught all of them.
(3) Use libmap to perform the necessary substitution on a per-application
or per-system basis. If libpthread isn't available on an
architecture, default ship libmap.conf to substitute libthr for
libpthread on the platform for all applications. Or libc_r, or
whatever.
This will result in all applications we ship having a consistent thread
library name so that administrators can substitute more easily. libpthread
would give you M:N threading by default, but it would be easy to perform
local changes to improve performance for applications that specifically
benefit from 1:1 threading, cothreads, etc. Or if a serious compatibility
bug is found between libpthread and an application, they can substitute
easily as well. I suppose this case might imply (4):
(4) If an application is known to be compatible only with a specific
threading model, do hard-code that in the application build somehow.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
