Re: configure fails with threads again

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>  pthread_create() doesn't work as expected.
> 
>>configure: error: pthread.h and pthread_create are not compatible
>  give up, environment is inconsistent.
> 
> I consider this is vendor bug.  Sun should provide a consistent
> environment.

Consistent?  The have provided a thread package and manual pages on how
to use it (with -mt).  It's not their fault that configure tries to use
it in an undocumented way.

Still, the configure test would have worked if it used all the options
which configure itself has found that other programs need.  That is,
-D_REENTRANT ... -lpthread in this case.

> If a pthread_create() exists in the installer provided flags, we
> expect it to work.

And I believe that's one of the main complaint against autoconf in the
autoconf/metaconfig wars.

The pthread_create in libc appears to be a dummy routine, probably
provided so that packages compiled for optional threading will link
properly without threads.  It does not create a thread, and returns an
error status to indicate that.  I believe this is a pretty common
technique.  I've used it myself for one of my packages, and I've heard
about others.

> Placing
> 	ac_cv_func_pthread_create=${ac_cv_func_pthread_create='no'}
> 
> into an empty config.cache before running ./configure would disable
> this test.

True, but that's not the kind of thing users should be required to know.

> Suggestions on how to beter handle this vendor bug that do not
> restrict the use of alternative thread packages would be welcomed.

1. Suggest to users that they read `man cc' and provide the proper flags
   to CC for threading, so threading packages are used the way they are
   indented to be used.  (And say that configure will try to figure
   it out in any case, of course.)

2. Make configure use the flags it figures out that we need to use.

   BTW, I stumbled over another case of that one recently:
      CFLAGS=-I/local/gnu/include LDFLAGS=-L/local/gnu/lib ./configure
   didn't find gdbm.h because it searches for it with $ac_cpp,
   which contains $CPPFLAGS but not $CFLAGS.

   Fix:  Add $CFLAGS to $ac_cpp.

-- 
Hallvard