Todd Vierling wrote:
> On Tue, 23 Nov 2004, Nathan J. Williams wrote:
> 
> > Thinking about this more, a better answer might be for <pthread.h> to
> > #define pthread_mutex_lock(x) to __libc_mutex_lock(x), so that ~all
> > code that is written to use locking routines from pthread.h will go
> > through the libc redirection by default,
> 
> You know, I was thinking about this today and was going to ask precisely
> this question.  (And isn't this what Solaris does/did, at least with the old
> libthread if not libpthread?)

Solaris has its own problems in with demand loading a threads
dependent object at run-time.  They have a libthread implementation
of sigaction that replaces the libc version, and loading a threaded
object into a non-threaded application "forgets" what the previously
installed handler was. This has broken the signal management protocol
in a commercial application that I work with.

To solve the pkgsrc issues, you cannot portably dlopen() a threaded
object from a non-threaded application. Threads support has to be
in place before main() is called, and probably before C++ static
constructors get invoked.

/sjd