[krbdev.mit.edu #5563] need feature tests for deciding when to use pthread code

[Ken Raeburn via RT]

The fix I put in for ticket 5560 tests for the OS name and version to decide whether to use 
the pthread support unconditionally.  (The thread library exists, but just re-points us to the 
support in libc that's available anyways.)  There are also checks for AIX and Tru64 that turn 
on the thread support unconditionally.  (I believe on both systems we don't get any stub 
versions in libc, and we don't get weak references.  On AIX, though, I think we get the thread 
library loaded in when dlopen is used, so dynamically loaded code can use thread support.)

Proper feature tests should probably be worked out for these cases, so that other systems 
with similar attributes can avoid the run-time conditional tests and just call the pthread 
routines directly.

The annoying part of this is probably going to be figuring out what the right properties are 
that we want to test for.

In the Solaris case -- pthread support available in libc -- the thread support functions 
should be available and the mutex and once functionality should work.  Eventually we may 
want to test condition variables and thread creation.  (Though in the short term, I only expect 
those to be used in main program code, not library code, so we can force that program to 
link with the thread library and use condition variables unconditionally, even when the 
library's use of mutexes has to test for the support first.)

On AIX, we get: no weak symbol support; stub functions not available in libc; dlopen finds 
pthread symbols, even looking at an object not linked with the thread library specifically.

On Tru64, we have: no weak symbols; stub functions not available in libc.  Since having 
dlopen pull in the thread library is a bit dicey in general, we may not want this to 
automatically pull in thread support, but the alternative is to build with no thread support at 
all.  Or maybe use dlopen(NULL) to look for pthread support in the main program?