Re: configure can't detect proper pthread flags

On 03/21/2015 01:06 AM, Max Filippov wrote:
> On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov <jcmvbkbc(at)gmail(dot)com> wrote:
>> Ok, one more attempt: maybe instead of checking that stderr is empty
>> we could check that stderr has changed in the presence of the option
>> that we test?
>
> The patch:
> http://www.postgresql.org/message-id/1426860321-13586-1-git-send-email-jcmvbkbc@gmail.com

Let's step back a bit. If I understand correctly, we have that "does
-foo compiler option produce a warning?" check because we're trying all
the different pthread-related flags, and use everything that works. We
don't want to use flags that add warnings, however, so we need that
check. But why do we try to use all the flags, and not just the first
one that works? The original script stopped at the first one that works,
but we changed that in this commit:

commit e48322a6d6cfce1ec52ab303441df329ddbc04d1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Thu Aug 12 16:39:50 2004 +0000

Be more aggressive about adding flags to thread compiles. The
configure
test only tests for building a binary, not building a shared library.

On Linux, you can build a binary with -pthread, but you can't build a
binary that uses a threaded shared library unless you also use -pthread
when building the binary, or adding -lpthread to the shared library
build. This patch has the effect of doing the later by adding both
-pthread and -lpthread when building libpq.

The discussion that lead to that commit is here:
http://www.postgresql.org/message-id/flat/200408101453(dot)36209(dot)xzilla(at)users(dot)sourceforge(dot)net#200408101453(dot)36209(dot)xzilla@users.sourceforge.net.

I tried reverting that commit, and lo-and-behold everything still works.
Turns out that using -lpthread is not in fact necessary when building
libpq on Linux. It seems that it was in fact a GCC bug all along, that
it didn't link the shared library with libpthread, when you passed just
the -pthread flag; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8888.

I suggest that we revert that work-around for that GCC bug, and stop
testing the pthread flags as soon as we find one that works. Then we can
also remove the test for whether the compiler produces any warnings.
AFAICS, after that our ax_thread.m4 file is not materially different
from the upstream autoconf-archive version. Let's just replace our
ax_pthread.m4 file with the latest upstream version.

Of course, that breaks this again for anyone compiling on Linux with GCC
version 3.2 or older. I don't have much sympathy for that old systems,
and there is a work-around available for them anyway: specify
PTHREAD_CFLAGS="-pthread -lpthread" on the configure command line. Then
the configure script will just verify that that works, and not run the
auto-detection code. You can also use that work-around to build older
branches with uClibc, which produces the annoying gethostbyname()
warnings that started this thread. To err on the side of caution, I'm
thinking this should be committed to master and REL9_5_STABLE only.

Thoughts?

- Heikki