[Date Prev][Date Next]
Re: configure fails with threads again
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
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
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
> 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.