Hi Pavel


I am afraid this patch WILL lead to breakage on systems that do not have a
library called "pthread" and use the GCC suite/g++. Another point of discussion
might be if libtool should catch situations in which users explicitly(!) set
both the -nostdlib and -pthread(s) compiler flags and add appropriate library
dependencies, but that might be too much magic.

Finding the actual library implementing portable threads support is non-trivial,
which is why helpers like AX_PTHREAD exist. For instance, some systems put the
implementation in libpthread.sharedext, while others put it in
libpthreads.sharedext (note the additional s) and even others put it into libc
directly without a special library (e.g., Darwin). Worse, there are systems out
there (or have existed historically) like DEC UNIX that have both a
libpthread.sharedext and libpthreads.sharedext library, with the former
implementing the proper portable threads standard, while the latter
implements... something called DECthreads based on the CMA (Compaq-proprietary)
and DCE threaded (some early POSIX draft(!)) interfaces.


I'll submit a patch to the GNU Autoconf Archive to work around that bug in
AX_PTHREAD by adding the first found pthread library to PTHREAD_LIBS if gcc is
being used (as the C compiler, anyway, because AX_PTHREAD always checks using C,
which should be mostly fine, but that's a different topic) and the -pthread
compiler flag is being checked as candidate for enabling pthread support.


Nevertheless, this bug has been around for more than 10 years now and I'd really
like to finally see it fixed, because working around it is getting really old.



Mihai