Configure not selecting proper -pthread options

[Kevin Teich]

Hello,

I've noticed some strange behavior with the options that configure chooses 
for compiling pthread code. I'm on a Red Hat Linux 7.3 machine using 
autoconf 2.57 and automake 1.6.3.

We use the ACX_PTHREAD macro from ac-archive to configure pthread options, 
from http://www.gnu.org/software/ac-archive/htmldoc/acx_pthread.html . 
configure would execute successfully and determine that -pthread was the 
correct option for this machine, but our programs would not compile, the 
Makefiles generating link errors for undefined pthread symbols.

The reason for this is that when configure does its test to figure out how 
to handle pthreads, it uses a combined compile/link line when testing 
various options. The test it does for -pthread is to set CFLAGS to 
-pthread and leave LIBS blank, and it generates a test like this:

gcc -c -o conftest -pthread test.c

This compiles fine, presumably because gcc breaks this down into two 
separate steps:

gcc -c test.c -pthread
gcc -o conftest test.o -pthread

So configure sets PTHREAD_CFLAGS to -pthread and PTHREAD_LIBS to nothing.

But, gcc wants -pthread on both its compile line and its link line. I 
don't know enough about gcc to know why, but I've verified it with a tiny 
test program on my own. (For the link line, you can acutally use -pthread 
or -lpthread.)

So when the generated makefile starts building stuff, it does it in the 
normal two steps. So we'd get something like:

gcc -c main.c $PTHREADS_CFLAGS        (= -pthread)
gcc -o main $PTHREADS_LIBS            (= empty)

And get a link error. So I added some code to the acinclude.m4 that checks 
to see if configure determined that -pthread was the thing to use, and if 
so, to also add it to PTHREAD_LIBS:

if test x"$PTHREAD_CFLAGS" = x-pthread; then
  PTHREAD_LIBS="-pthread"
fi

This solved our problem.

Is this a bug, or a logic error in the ACX_PTHREAD macro, or a 
misconfiguration on my part? Did I do the correct thing to fix it, or is 
there another work-around?

Thanks.


--
Kevin Teich