On Fri, 20 Mar 2009, Coleman Kane wrote:
I've found that many of the GNU apps are notorious for this. I really can't
say that I know why libassuan or gnupg explicitly require GNU pth, rather
than first attempting to use POSIX pthread API. Their configure scripts both
want to search for and run pth-config, and fail to enable some sort of
threaded features if it doesn't exist. I already tried removing pth stuff
from both port Makefiles to see what would happen. I didn't spend much time
on it after I figured out that devel/pth would just work if I removed the
signal.h include.
I am guessing that some non-standard extensions which GNU pth provides are
not provided by the normal POSIX spec.
In fact, libassuan just goes ahead and uses a bunch of pth_* overrides for
dealing with them in a thread-safe manner (waitpid, read, write, select,
usleep).
Historically, pthreads implementations were highly variable in quality,
completeness, etc. It wouldn't surprise me if the persistence of applications
linking against pth isn't, in part, a response to that (now-historic)
situation.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
