configure can't detect proper pthread flags
Hi,
when PostgreSQL is cross-compiled in the Buildroot with uClibc toolchain
it may not correctly detect compiler/linker flags for threading. [1]http://comments.gmane.org/gmane.comp.lib.uclibc.buildroot/110204
The reason is that config/acx_pthread.m4:146 uses compiler and linker
stdout and stderr to make decision if acx_pthread_ok should be yes or no:
if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval
$ac_compile 2>&1 1>&5)`" = ""; then
and the toolchain emits the following warning at linking step:
libcrypto.so: warning: gethostbyname is obsolescent, use
getnameinfo() instead.
git log doesn't tell much why it is done that way. Does anybody know?
Can that test be rewritten as
if eval $ac_link 2>&1 1>&5 && eval $ac_compile 2>&1 1>&5 ; then
?
[1]: http://comments.gmane.org/gmane.comp.lib.uclibc.buildroot/110204
--
Thanks.
-- Max
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Max Filippov <jcmvbkbc@gmail.com> writes:
when PostgreSQL is cross-compiled in the Buildroot with uClibc toolchain
it may not correctly detect compiler/linker flags for threading. [1]
The reason is that config/acx_pthread.m4:146 uses compiler and linker
stdout and stderr to make decision if acx_pthread_ok should be yes or no:
if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval
$ac_compile 2>&1 1>&5)`" = ""; then
and the toolchain emits the following warning at linking step:
libcrypto.so: warning: gethostbyname is obsolescent, use
getnameinfo() instead.
git log doesn't tell much why it is done that way. Does anybody know?
The short answer is that the linker you're using is written by pedantic
idiots. Notice that the gethostbyname call it's complaining about is
somewhere inside libcrypto; it's *not* in Postgres, much less the test
program being built here. As such, we have no options whatever for
suppressing the complaint, which means that the complaint is being
delivered inappropriately, and it shouldn't be there. The linker is a
silly choice for a place to impose this sort of value judgment anyway;
it has absolutely no way to know whether the use of gethostbyname in
a particular program is unsafe.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval
$ac_compile 2>&1 1>&5)`" = ""; then
FWIW, I happened to run into this recently on IRC with someone having
compile problems on FreeBSD (10.1); they were using some nonstandard
compile flags, and configure's pthread test was breaking as a result
(they did not report what the actual warning was).
While investigating that, I also noticed that this code prevents any
attempt at running configure with -x in effect from working properly,
making it a bit hard to debug.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Tom,
On Fri, Mar 20, 2015 at 3:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Max Filippov <jcmvbkbc@gmail.com> writes:
when PostgreSQL is cross-compiled in the Buildroot with uClibc toolchain
it may not correctly detect compiler/linker flags for threading. [1]
The reason is that config/acx_pthread.m4:146 uses compiler and linker
stdout and stderr to make decision if acx_pthread_ok should be yes or no:if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval
$ac_compile 2>&1 1>&5)`" = ""; thenand the toolchain emits the following warning at linking step:
libcrypto.so: warning: gethostbyname is obsolescent, use
getnameinfo() instead.git log doesn't tell much why it is done that way. Does anybody know?
The short answer is that the linker you're using is written by pedantic
idiots.
Well... That doesn't answer my question.
Notice that the gethostbyname call it's complaining about is
somewhere inside libcrypto; it's *not* in Postgres, much less the test
program being built here.
Actually it *is* in the program being built here, because it's being
linked with libcrypto. The full command line produced by the first eval
is this:
xtensa-linux-gcc -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mlongcalls
-mtext-section-literals -Os -pthread -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE conftest.c
-lssl -lcrypto -lz -lreadline -lrt -lcrypt -ldl -lm
and if I drop irrelevant libraries from that command its stdout+stderr
will probably be empty.
But I was curious why this test is written *that* way.
--
Thanks.
-- Max
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 04:51:55AM +0300, Max Filippov wrote:
xtensa-linux-gcc -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mlongcalls
-mtext-section-literals -Os -pthread -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE conftest.c
-lssl -lcrypto -lz -lreadline -lrt -lcrypt -ldl -lmand if I drop irrelevant libraries from that command its stdout+stderr
will probably be empty.But I was curious why this test is written *that* way.
Threading compiles are different for every platform so the code just
tries everything --- we didn't anticipate that adding a useless library
would actually cause a failure.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 5:09 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 20, 2015 at 04:51:55AM +0300, Max Filippov wrote:
xtensa-linux-gcc -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mlongcalls
-mtext-section-literals -Os -pthread -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE conftest.c
-lssl -lcrypto -lz -lreadline -lrt -lcrypt -ldl -lmand if I drop irrelevant libraries from that command its stdout+stderr
will probably be empty.But I was curious why this test is written *that* way.
Threading compiles are different for every platform so the code just
tries everything --- we didn't anticipate that adding a useless library
would actually cause a failure.
Sorry, I must be not clear enough: why checking compiler/linker output
instead of checking their exit code or presence of produced object/
executable files?
--
Thanks.
-- Max
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Max" == Max Filippov <jcmvbkbc@gmail.com> writes:
Max> Sorry, I must be not clear enough: why checking compiler/linker
Max> output instead of checking their exit code or presence of produced
Max> object/ executable files?
Going by the comment some lines above, my guess would be "because some
compilers accept some option like -pthreads and issue a warning message
saying that it is ignored, and pg wants to not treat such options as
valid"
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 05:15:51AM +0300, Max Filippov wrote:
On Fri, Mar 20, 2015 at 5:09 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 20, 2015 at 04:51:55AM +0300, Max Filippov wrote:
xtensa-linux-gcc -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mlongcalls
-mtext-section-literals -Os -pthread -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE conftest.c
-lssl -lcrypto -lz -lreadline -lrt -lcrypt -ldl -lmand if I drop irrelevant libraries from that command its stdout+stderr
will probably be empty.But I was curious why this test is written *that* way.
Threading compiles are different for every platform so the code just
tries everything --- we didn't anticipate that adding a useless library
would actually cause a failure.Sorry, I must be not clear enough: why checking compiler/linker output
instead of checking their exit code or presence of produced object/
executable files?
Oh, uh, I don't rember the answer to that one. I think the code is in
config/acx_pthread.m4 and I assume we are just checking using the
configure macros that are provided.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
"Max" == Max Filippov <jcmvbkbc@gmail.com> writes:
Max> Sorry, I must be not clear enough: why checking compiler/linker
Max> output instead of checking their exit code or presence of produced
Max> object/ executable files?
Going by the comment some lines above, my guess would be "because some
compilers accept some option like -pthreads and issue a warning message
saying that it is ignored, and pg wants to not treat such options as
valid"
Precisely. We don't want every link step producing a useless warning.
Ideally, "make -s" would print nothing whatsoever; to the extent that
tools produce unsuppressable routine chatter, that's evil because it
makes it harder to notice actually-useful warnings.
(My current ambition in this area is to shut up clang from complaining
like so:
clang: warning: argument unused during compilation: '-pthread'
clang: warning: argument unused during compilation: '-pthread'
clang: warning: argument unused during compilation: '-pthread'
clang: warning: argument unused during compilation: '-pthread'
clang: warning: argument unused during compilation: '-pthread'
which is another bit of entirely useless pedantry, but rather hard to work
around because we assume that CFLAGS should be included when linking.)
It's tempting to consider avoiding Max's problem by doing the ACX_PTHREAD
test before picking up any other libraries. But I'm worried that that
would cause more problems than it solves. It's worth noting that the
Autoconf documentation specifically recommends testing for libraries
before testing for compiler characteristics.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 5:20 AM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
"Max" == Max Filippov <jcmvbkbc@gmail.com> writes:
Max> Sorry, I must be not clear enough: why checking compiler/linker
Max> output instead of checking their exit code or presence of produced
Max> object/ executable files?Going by the comment some lines above, my guess would be "because some
compilers accept some option like -pthreads and issue a warning message
saying that it is ignored, and pg wants to not treat such options as
valid"
I've somehow missed that comment, thank you Andrew.
-- Max
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
We don't want every link step producing a useless warning.
Ideally, "make -s" would print nothing whatsoever; to the extent that
tools produce unsuppressable routine chatter, that's evil because it
makes it harder to notice actually-useful warnings.
Then maybe stderr tests should grep output for a specific option, the
one we're currently testing, not just any noise?
--
Thanks.
-- Max
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 7:01 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
We don't want every link step producing a useless warning.
Ideally, "make -s" would print nothing whatsoever; to the extent that
tools produce unsuppressable routine chatter, that's evil because it
makes it harder to notice actually-useful warnings.Then maybe stderr tests should grep output for a specific option, the
one we're currently testing, not just any noise?
That sounds awfully fragile to me. It can't really be safe to assume
we know precisely what the warning messages will look like. But it
seems to me that compiling every test program with every library we
might need is not a great plan.
(I don't know enough about autoconf to know whether changing that is realistic.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 08:05:48AM -0400, Robert Haas wrote:
On Fri, Mar 20, 2015 at 7:01 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
We don't want every link step producing a useless warning.
Ideally, "make -s" would print nothing whatsoever; to the extent that
tools produce unsuppressable routine chatter, that's evil because it
makes it harder to notice actually-useful warnings.Then maybe stderr tests should grep output for a specific option, the
one we're currently testing, not just any noise?That sounds awfully fragile to me. It can't really be safe to assume
we know precisely what the warning messages will look like. But it
seems to me that compiling every test program with every library we
might need is not a great plan.(I don't know enough about autoconf to know whether changing that is realistic.)
It was our only plan, and it has worked fine in the past. Someone is
going to have to do a lot of portability research to improve it.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 3:05 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Mar 20, 2015 at 7:01 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
We don't want every link step producing a useless warning.
Ideally, "make -s" would print nothing whatsoever; to the extent that
tools produce unsuppressable routine chatter, that's evil because it
makes it harder to notice actually-useful warnings.Then maybe stderr tests should grep output for a specific option, the
one we're currently testing, not just any noise?That sounds awfully fragile to me. It can't really be safe to assume
we know precisely what the warning messages will look like.
Yes, I agree, not very good.
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?
--
Thanks.
-- Max
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2015-03-20 03:14:48 +0300, Max Filippov wrote:
and the toolchain emits the following warning at linking step:
libcrypto.so: warning: gethostbyname is obsolescent, use
getnameinfo() instead.
FWIW, I think emitting such errors at link time is utterly pointless and
rather annoying. I can see a point of emitting them them when compiling
code that uses deprecated functions. But we quite obviously can't do
much about openssl using gethostbyname.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund wrote:
Hi,
On 2015-03-20 03:14:48 +0300, Max Filippov wrote:
and the toolchain emits the following warning at linking step:
libcrypto.so: warning: gethostbyname is obsolescent, use
getnameinfo() instead.FWIW, I think emitting such errors at link time is utterly pointless and
rather annoying. I can see a point of emitting them them when compiling
code that uses deprecated functions. But we quite obviously can't do
much about openssl using gethostbyname.
We don't seem have much leverage with the guys producing the linker. If
we do, then surely our best bet is to get them to be quiet, or at least
provide an --yes-i-know-your-crap-is-noisy-please-shut-it-up option.
If we don't have leverage, and we really care enough about that platform
to want to work around this problem, it seems that the latest suggestion
of comparing the output of the linker with and without the option we're
testing (rather than just assuming that the output without the option
must surely be empty) is the safest bet ... It seems bad (fragile
hack), but let's see a patch and then we can judge.
Another option is to say "uclibc is broken beyond belief" and consider
it unsupported.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-03-20 10:23:51 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
FWIW, I think emitting such errors at link time is utterly pointless and
rather annoying. I can see a point of emitting them them when compiling
code that uses deprecated functions. But we quite obviously can't do
much about openssl using gethostbyname.We don't seem have much leverage with the guys producing the linker. If
we do, then surely our best bet is to get them to be quiet, or at least
provide an --yes-i-know-your-crap-is-noisy-please-shut-it-up option.
It's not the linker, it's uclibc that adds the warning.
http://git.uclibc.org/uClibc/commit/?id=fdc6f045fa8b71a91a0c55b6390f8d0741e9f374
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund wrote:
On 2015-03-20 10:23:51 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
FWIW, I think emitting such errors at link time is utterly pointless and
rather annoying. I can see a point of emitting them them when compiling
code that uses deprecated functions. But we quite obviously can't do
much about openssl using gethostbyname.We don't seem have much leverage with the guys producing the linker. If
we do, then surely our best bet is to get them to be quiet, or at least
provide an --yes-i-know-your-crap-is-noisy-please-shut-it-up option.It's not the linker, it's uclibc that adds the warning.
http://git.uclibc.org/uClibc/commit/?id=fdc6f045fa8b71a91a0c55b6390f8d0741e9f374
Wow, that stuff has been there since 2009. So there's no way to shut it
up at all, is there.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
By the way, acx-pthread.m4 has an outdated link to upstream
acx_pthread.m4. The correct link is
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax_pthread.m4
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Robert" == Robert Haas <robertmhaas@gmail.com> writes:
Then maybe stderr tests should grep output for a specific option,
the one we're currently testing, not just any noise?
Robert> That sounds awfully fragile to me. It can't really be safe to
Robert> assume we know precisely what the warning messages will look
Robert> like.
But how safe is it to assume that a warning message about option '-foo'
will contain the string '-foo' in it somewhere?
(though the trace output from -x still should be dealt with separately)
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 2:51 PM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
"Robert" == Robert Haas <robertmhaas@gmail.com> writes:
Then maybe stderr tests should grep output for a specific option,
the one we're currently testing, not just any noise?Robert> That sounds awfully fragile to me. It can't really be safe to
Robert> assume we know precisely what the warning messages will look
Robert> like.But how safe is it to assume that a warning message about option '-foo'
will contain the string '-foo' in it somewhere?(though the trace output from -x still should be dealt with separately)
I wouldn't like to bet on it. I mean, if the world weren't full of
weird platforms that behave in crazy, messed-up ways, autoconf output
wouldn't look like like noise.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov <jcmvbkbc@gmail.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:
/messages/by-id/1426860321-13586-1-git-send-email-jcmvbkbc@gmail.com
--
Thanks.
-- Max
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov <jcmvbkbc@gmail.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:
/messages/by-id/1426860321-13586-1-git-send-email-jcmvbkbc@gmail.com
Ping?
Are there any issues with that approach and the patch?
--
Thanks.
-- Max
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 8, 2015 at 2:31 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov <jcmvbkbc@gmail.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:
/messages/by-id/1426860321-13586-1-git-send-email-jcmvbkbc@gmail.comPing?
Are there any issues with that approach and the patch?
I think the thing to do is add your patch here so that it doesn't get
forgotten about:
https://commitfest.postgresql.org/action/commitfest_view/open
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Apr 30, 2015 at 3:51 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Apr 8, 2015 at 2:31 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov <jcmvbkbc@gmail.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:
/messages/by-id/1426860321-13586-1-git-send-email-jcmvbkbc@gmail.comPing?
Are there any issues with that approach and the patch?I think the thing to do is add your patch here so that it doesn't get
forgotten about:https://commitfest.postgresql.org/action/commitfest_view/open
Done: https://commitfest.postgresql.org/5/232/
--
Thanks.
-- Max
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/21/2015 01:06 AM, Max Filippov wrote:
On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov <jcmvbkbc@gmail.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:
/messages/by-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@momjian.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:
/messages/by-id/200408101453.36209.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
Attachments:
0001-Replace-our-hacked-version-of-ax_pthread.m4-with-lat.patchtext/x-diff; name=0001-Replace-our-hacked-version-of-ax_pthread.m4-with-lat.patchDownload
>From 711e5c7a1762f0c12e7b7e457c84484827246086 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: Wed, 8 Jul 2015 11:11:18 +0300
Subject: [PATCH 1/1] Replace our hacked version of ax_pthread.m4 with latest
upstream version.
Our version was different from the upstream version in that we tried to use
all possible pthread-related flags that the compiler accepts, rather than
just the first one that works. That was changed in commit
e48322a6d6cfce1ec52ab303441df329ddbc04d1, which was needed to work-around a
GCC bug that was fixed in GCC version 3.3, and we hardly care about such an
old version anymore (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8888).
This fixes the detection for compilers that print warnings with the chosen
flags. That's pretty annoying on its own right, but it's not nice that it
inconspicuously disables thread-safety.
If you really want to compile with GCC version 3.2 or older, you can still
work-around it manually by setting PTHREAD_CFLAGS="-pthread -lpthread"
manually on the configure command line.
---
aclocal.m4 | 2 +-
config/acx_pthread.m4 | 170 --------------------------
config/ax_pthread.m4 | 332 ++++++++++++++++++++++++++++++++++++++++++++++++++
configure | 310 ++++++++++++++++++++++++++++++++++++----------
configure.in | 2 +-
5 files changed, 583 insertions(+), 233 deletions(-)
delete mode 100644 config/acx_pthread.m4
create mode 100644 config/ax_pthread.m4
diff --git a/aclocal.m4 b/aclocal.m4
index eaf9800..6f930b6 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -1,6 +1,6 @@
dnl aclocal.m4
m4_include([config/ac_func_accept_argtypes.m4])
-m4_include([config/acx_pthread.m4])
+m4_include([config/ax_pthread.m4])
m4_include([config/c-compiler.m4])
m4_include([config/c-library.m4])
m4_include([config/docbook.m4])
diff --git a/config/acx_pthread.m4 b/config/acx_pthread.m4
deleted file mode 100644
index 793b7b7..0000000
--- a/config/acx_pthread.m4
+++ /dev/null
@@ -1,170 +0,0 @@
-dnl This is based on an old macro from the GNU Autoconf Macro Archive at:
-dnl http://www.gnu.org/software/ac-archive/htmldoc/acx_pthread.html
-dnl but it's been rather heavily hacked --- beware of blindly dropping in
-dnl upstream changes!
-dnl
-AC_DEFUN([ACX_PTHREAD], [
-AC_REQUIRE([AC_CANONICAL_HOST])
-AC_LANG_PUSH([C])
-acx_pthread_ok=no
-
-# We used to check for pthread.h first, but this fails if pthread.h
-# requires special compiler flags (e.g. on True64 or Sequent).
-# It gets checked for in the link test anyway.
-
-# First of all, check if the user has set any of the PTHREAD_LIBS,
-# etcetera environment variables, and if threads linking works using
-# them:
-if test x"$PTHREAD_LIBS$PTHREAD_CFLAGS" != x; then
- save_CFLAGS="$CFLAGS"
- CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
- save_LIBS="$LIBS"
- LIBS="$PTHREAD_LIBS $LIBS"
- AC_MSG_CHECKING([for pthread_join in LIBS=$PTHREAD_LIBS with CFLAGS=$PTHREAD_CFLAGS])
- AC_TRY_LINK_FUNC(pthread_join, acx_pthread_ok=yes)
- AC_MSG_RESULT($acx_pthread_ok)
- if test x"$acx_pthread_ok" = xno; then
- PTHREAD_LIBS=""
- PTHREAD_CFLAGS=""
- fi
- LIBS="$save_LIBS"
- CFLAGS="$save_CFLAGS"
-fi
-
-# We must check for the threads library under a number of different
-# names; the ordering is very important because some systems
-# (e.g. DEC) have both -lpthread and -lpthreads, where one of the
-# libraries is broken (non-POSIX).
-
-# Create a list of thread flags to try. Items starting with a "-" are
-# C compiler flags, and other items are library names, except for "none"
-# which indicates that we try without any flags at all, and "pthread-config"
-# which is a program returning the flags for the Pth emulation library.
-
-acx_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config pthreadGC2"
-
-# The ordering *is* (sometimes) important. Some notes on the
-# individual items follow:
-
-# pthreads: AIX (must check this before -lpthread)
-# none: in case threads are in libc; should be tried before -Kthread and
-# other compiler flags to prevent continual compiler warnings
-# -Kthread: Sequent (threads in libc, but -Kthread needed for pthread.h)
-# -kthread: FreeBSD kernel threads (preferred to -pthread since SMP-able)
-# lthread: LinuxThreads port on FreeBSD (also preferred to -pthread)
-# -pthread: Linux/gcc (kernel threads), BSD/gcc (userland threads)
-# -pthreads: Solaris/gcc
-# -mthreads: Mingw32/gcc, Lynx/gcc
-# -mt: Sun Workshop C (may only link SunOS threads [-lthread], but it
-# doesn't hurt to check since this sometimes defines pthreads too;
-# also defines -D_REENTRANT)
-# pthread: Linux, etcetera
-# --thread-safe: KAI C++
-# pthread-config: use pthread-config program (for GNU Pth library)
-
-case "${host_cpu}-${host_os}" in
- *solaris*)
-
- # On Solaris (at least, for some versions), libc contains stubbed
- # (non-functional) versions of the pthreads routines, so link-based
- # tests will erroneously succeed. (We need to link with -pthread or
- # -lpthread.) (The stubs are missing pthread_cleanup_push, or rather
- # a function called by this macro, so we could check for that, but
- # who knows whether they'll stub that too in a future libc.) So,
- # we'll just look for -pthreads and -lpthread first:
-
- acx_pthread_flags="-pthread -pthreads pthread -mt $acx_pthread_flags"
- ;;
-esac
-
-if test x"$acx_pthread_ok" = xno; then
-for flag in $acx_pthread_flags; do
-
- tryPTHREAD_CFLAGS=""
- tryPTHREAD_LIBS=""
- case $flag in
- none)
- AC_MSG_CHECKING([whether pthreads work without any flags])
- ;;
-
- -*)
- AC_MSG_CHECKING([whether pthreads work with $flag])
- tryPTHREAD_CFLAGS="$flag"
- ;;
-
- pthread-config)
- # skip this if we already have flags defined, for PostgreSQL
- if test x"$PTHREAD_CFLAGS" != x -o x"$PTHREAD_LIBS" != x; then continue; fi
- AC_CHECK_PROG(acx_pthread_config, pthread-config, yes, no)
- if test x"$acx_pthread_config" = xno; then continue; fi
- tryPTHREAD_CFLAGS="`pthread-config --cflags`"
- tryPTHREAD_LIBS="`pthread-config --ldflags` `pthread-config --libs`"
- ;;
-
- *)
- AC_MSG_CHECKING([for the pthreads library -l$flag])
- tryPTHREAD_LIBS="-l$flag"
- ;;
- esac
-
- save_LIBS="$LIBS"
- save_CFLAGS="$CFLAGS"
- LIBS="$tryPTHREAD_LIBS $PTHREAD_LIBS $LIBS"
- CFLAGS="$CFLAGS $PTHREAD_CFLAGS $tryPTHREAD_CFLAGS"
-
- # Check for various functions. We must include pthread.h,
- # since some functions may be macros. (On the Sequent, we
- # need a special flag -Kthread to make this header compile.)
- # We check for pthread_join because it is in -lpthread on IRIX
- # while pthread_create is in libc. We check for pthread_attr_init
- # due to DEC craziness with -lpthreads. We check for
- # pthread_cleanup_push because it is one of the few pthread
- # functions on Solaris that doesn't have a non-functional libc stub.
- # We try pthread_create on general principles.
- AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <pthread.h>],
- [pthread_t th; pthread_join(th, 0);
- pthread_attr_init(0); pthread_cleanup_push(0, 0);
- pthread_create(0,0,0,0); pthread_cleanup_pop(0); ])],
- [acx_pthread_ok=yes], [acx_pthread_ok=no])
-
- if test "x$acx_pthread_ok" = xyes; then
- # Don't use options that are ignored by the compiler.
- # We find them by checking stderror.
- cat >conftest.$ac_ext <<_ACEOF
-int
-main (int argc, char **argv)
-{
- (void) argc;
- (void) argv;
- return 0;
-}
-_ACEOF
- rm -f conftest.$ac_objext conftest$ac_exeext
- # Check both linking and compiling, because they might tolerate different options.
- if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval $ac_compile 2>&1 1>&5)`" = ""; then
- # The original macro breaks out of the loop at this point,
- # but we continue trying flags because Linux needs -lpthread
- # too to build libpq successfully. The test above only
- # tests for building binaries, not shared libraries.
- PTHREAD_LIBS=" $tryPTHREAD_LIBS $PTHREAD_LIBS"
- PTHREAD_CFLAGS="$PTHREAD_CFLAGS $tryPTHREAD_CFLAGS"
- else acx_pthread_ok=no
- fi
- fi
-
- LIBS="$save_LIBS"
- CFLAGS="$save_CFLAGS"
-
- AC_MSG_RESULT($acx_pthread_ok)
-done
-fi
-
-# The original macro has a bunch of other tests here, which we have removed
-# because (a) Postgres doesn't need them, and (b) $acx_pthread_ok is not
-# meaningful at this point.
-
-AC_SUBST(PTHREAD_LIBS)
-AC_SUBST(PTHREAD_CFLAGS)
-
-AC_LANG_POP([C])
-])dnl ACX_PTHREAD
diff --git a/config/ax_pthread.m4 b/config/ax_pthread.m4
new file mode 100644
index 0000000..d383ad5
--- /dev/null
+++ b/config/ax_pthread.m4
@@ -0,0 +1,332 @@
+# ===========================================================================
+# http://www.gnu.org/software/autoconf-archive/ax_pthread.html
+# ===========================================================================
+#
+# SYNOPSIS
+#
+# AX_PTHREAD([ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
+#
+# DESCRIPTION
+#
+# This macro figures out how to build C programs using POSIX threads. It
+# sets the PTHREAD_LIBS output variable to the threads library and linker
+# flags, and the PTHREAD_CFLAGS output variable to any special C compiler
+# flags that are needed. (The user can also force certain compiler
+# flags/libs to be tested by setting these environment variables.)
+#
+# Also sets PTHREAD_CC to any special C compiler that is needed for
+# multi-threaded programs (defaults to the value of CC otherwise). (This
+# is necessary on AIX to use the special cc_r compiler alias.)
+#
+# NOTE: You are assumed to not only compile your program with these flags,
+# but also link it with them as well. e.g. you should link with
+# $PTHREAD_CC $CFLAGS $PTHREAD_CFLAGS $LDFLAGS ... $PTHREAD_LIBS $LIBS
+#
+# If you are only building threads programs, you may wish to use these
+# variables in your default LIBS, CFLAGS, and CC:
+#
+# LIBS="$PTHREAD_LIBS $LIBS"
+# CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+# CC="$PTHREAD_CC"
+#
+# In addition, if the PTHREAD_CREATE_JOINABLE thread-attribute constant
+# has a nonstandard name, defines PTHREAD_CREATE_JOINABLE to that name
+# (e.g. PTHREAD_CREATE_UNDETACHED on AIX).
+#
+# Also HAVE_PTHREAD_PRIO_INHERIT is defined if pthread is found and the
+# PTHREAD_PRIO_INHERIT symbol is defined when compiling with
+# PTHREAD_CFLAGS.
+#
+# ACTION-IF-FOUND is a list of shell commands to run if a threads library
+# is found, and ACTION-IF-NOT-FOUND is a list of commands to run it if it
+# is not found. If ACTION-IF-FOUND is not specified, the default action
+# will define HAVE_PTHREAD.
+#
+# Please let the authors know if this macro fails on any platform, or if
+# you have any other suggestions or comments. This macro was based on work
+# by SGJ on autoconf scripts for FFTW (http://www.fftw.org/) (with help
+# from M. Frigo), as well as ac_pthread and hb_pthread macros posted by
+# Alejandro Forero Cuervo to the autoconf macro repository. We are also
+# grateful for the helpful feedback of numerous users.
+#
+# Updated for Autoconf 2.68 by Daniel Richard G.
+#
+# LICENSE
+#
+# Copyright (c) 2008 Steven G. Johnson <stevenj@alum.mit.edu>
+# Copyright (c) 2011 Daniel Richard G. <skunk@iSKUNK.ORG>
+#
+# This program is free software: you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation, either version 3 of the License, or (at your
+# option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
+# Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+# As a special exception, the respective Autoconf Macro's copyright owner
+# gives unlimited permission to copy, distribute and modify the configure
+# scripts that are the output of Autoconf when processing the Macro. You
+# need not follow the terms of the GNU General Public License when using
+# or distributing such scripts, even though portions of the text of the
+# Macro appear in them. The GNU General Public License (GPL) does govern
+# all other use of the material that constitutes the Autoconf Macro.
+#
+# This special exception to the GPL applies to versions of the Autoconf
+# Macro released by the Autoconf Archive. When you make and distribute a
+# modified version of the Autoconf Macro, you may extend this special
+# exception to the GPL to apply to your modified version as well.
+
+#serial 21
+
+AU_ALIAS([ACX_PTHREAD], [AX_PTHREAD])
+AC_DEFUN([AX_PTHREAD], [
+AC_REQUIRE([AC_CANONICAL_HOST])
+AC_LANG_PUSH([C])
+ax_pthread_ok=no
+
+# We used to check for pthread.h first, but this fails if pthread.h
+# requires special compiler flags (e.g. on True64 or Sequent).
+# It gets checked for in the link test anyway.
+
+# First of all, check if the user has set any of the PTHREAD_LIBS,
+# etcetera environment variables, and if threads linking works using
+# them:
+if test x"$PTHREAD_LIBS$PTHREAD_CFLAGS" != x; then
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+ save_LIBS="$LIBS"
+ LIBS="$PTHREAD_LIBS $LIBS"
+ AC_MSG_CHECKING([for pthread_join in LIBS=$PTHREAD_LIBS with CFLAGS=$PTHREAD_CFLAGS])
+ AC_TRY_LINK_FUNC([pthread_join], [ax_pthread_ok=yes])
+ AC_MSG_RESULT([$ax_pthread_ok])
+ if test x"$ax_pthread_ok" = xno; then
+ PTHREAD_LIBS=""
+ PTHREAD_CFLAGS=""
+ fi
+ LIBS="$save_LIBS"
+ CFLAGS="$save_CFLAGS"
+fi
+
+# We must check for the threads library under a number of different
+# names; the ordering is very important because some systems
+# (e.g. DEC) have both -lpthread and -lpthreads, where one of the
+# libraries is broken (non-POSIX).
+
+# Create a list of thread flags to try. Items starting with a "-" are
+# C compiler flags, and other items are library names, except for "none"
+# which indicates that we try without any flags at all, and "pthread-config"
+# which is a program returning the flags for the Pth emulation library.
+
+ax_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config"
+
+# The ordering *is* (sometimes) important. Some notes on the
+# individual items follow:
+
+# pthreads: AIX (must check this before -lpthread)
+# none: in case threads are in libc; should be tried before -Kthread and
+# other compiler flags to prevent continual compiler warnings
+# -Kthread: Sequent (threads in libc, but -Kthread needed for pthread.h)
+# -kthread: FreeBSD kernel threads (preferred to -pthread since SMP-able)
+# lthread: LinuxThreads port on FreeBSD (also preferred to -pthread)
+# -pthread: Linux/gcc (kernel threads), BSD/gcc (userland threads)
+# -pthreads: Solaris/gcc
+# -mthreads: Mingw32/gcc, Lynx/gcc
+# -mt: Sun Workshop C (may only link SunOS threads [-lthread], but it
+# doesn't hurt to check since this sometimes defines pthreads too;
+# also defines -D_REENTRANT)
+# ... -mt is also the pthreads flag for HP/aCC
+# pthread: Linux, etcetera
+# --thread-safe: KAI C++
+# pthread-config: use pthread-config program (for GNU Pth library)
+
+case ${host_os} in
+ solaris*)
+
+ # On Solaris (at least, for some versions), libc contains stubbed
+ # (non-functional) versions of the pthreads routines, so link-based
+ # tests will erroneously succeed. (We need to link with -pthreads/-mt/
+ # -lpthread.) (The stubs are missing pthread_cleanup_push, or rather
+ # a function called by this macro, so we could check for that, but
+ # who knows whether they'll stub that too in a future libc.) So,
+ # we'll just look for -pthreads and -lpthread first:
+
+ ax_pthread_flags="-pthreads pthread -mt -pthread $ax_pthread_flags"
+ ;;
+
+ darwin*)
+ ax_pthread_flags="-pthread $ax_pthread_flags"
+ ;;
+esac
+
+# Clang doesn't consider unrecognized options an error unless we specify
+# -Werror. We throw in some extra Clang-specific options to ensure that
+# this doesn't happen for GCC, which also accepts -Werror.
+
+AC_MSG_CHECKING([if compiler needs -Werror to reject unknown flags])
+save_CFLAGS="$CFLAGS"
+ax_pthread_extra_flags="-Werror"
+CFLAGS="$CFLAGS $ax_pthread_extra_flags -Wunknown-warning-option -Wsizeof-array-argument"
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([int foo(void);],[foo()])],
+ [AC_MSG_RESULT([yes])],
+ [ax_pthread_extra_flags=
+ AC_MSG_RESULT([no])])
+CFLAGS="$save_CFLAGS"
+
+if test x"$ax_pthread_ok" = xno; then
+for flag in $ax_pthread_flags; do
+
+ case $flag in
+ none)
+ AC_MSG_CHECKING([whether pthreads work without any flags])
+ ;;
+
+ -*)
+ AC_MSG_CHECKING([whether pthreads work with $flag])
+ PTHREAD_CFLAGS="$flag"
+ ;;
+
+ pthread-config)
+ AC_CHECK_PROG([ax_pthread_config], [pthread-config], [yes], [no])
+ if test x"$ax_pthread_config" = xno; then continue; fi
+ PTHREAD_CFLAGS="`pthread-config --cflags`"
+ PTHREAD_LIBS="`pthread-config --ldflags` `pthread-config --libs`"
+ ;;
+
+ *)
+ AC_MSG_CHECKING([for the pthreads library -l$flag])
+ PTHREAD_LIBS="-l$flag"
+ ;;
+ esac
+
+ save_LIBS="$LIBS"
+ save_CFLAGS="$CFLAGS"
+ LIBS="$PTHREAD_LIBS $LIBS"
+ CFLAGS="$CFLAGS $PTHREAD_CFLAGS $ax_pthread_extra_flags"
+
+ # Check for various functions. We must include pthread.h,
+ # since some functions may be macros. (On the Sequent, we
+ # need a special flag -Kthread to make this header compile.)
+ # We check for pthread_join because it is in -lpthread on IRIX
+ # while pthread_create is in libc. We check for pthread_attr_init
+ # due to DEC craziness with -lpthreads. We check for
+ # pthread_cleanup_push because it is one of the few pthread
+ # functions on Solaris that doesn't have a non-functional libc stub.
+ # We try pthread_create on general principles.
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <pthread.h>
+ static void routine(void *a) { a = 0; }
+ static void *start_routine(void *a) { return a; }],
+ [pthread_t th; pthread_attr_t attr;
+ pthread_create(&th, 0, start_routine, 0);
+ pthread_join(th, 0);
+ pthread_attr_init(&attr);
+ pthread_cleanup_push(routine, 0);
+ pthread_cleanup_pop(0) /* ; */])],
+ [ax_pthread_ok=yes],
+ [])
+
+ LIBS="$save_LIBS"
+ CFLAGS="$save_CFLAGS"
+
+ AC_MSG_RESULT([$ax_pthread_ok])
+ if test "x$ax_pthread_ok" = xyes; then
+ break;
+ fi
+
+ PTHREAD_LIBS=""
+ PTHREAD_CFLAGS=""
+done
+fi
+
+# Various other checks:
+if test "x$ax_pthread_ok" = xyes; then
+ save_LIBS="$LIBS"
+ LIBS="$PTHREAD_LIBS $LIBS"
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+
+ # Detect AIX lossage: JOINABLE attribute is called UNDETACHED.
+ AC_MSG_CHECKING([for joinable pthread attribute])
+ attr_name=unknown
+ for attr in PTHREAD_CREATE_JOINABLE PTHREAD_CREATE_UNDETACHED; do
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <pthread.h>],
+ [int attr = $attr; return attr /* ; */])],
+ [attr_name=$attr; break],
+ [])
+ done
+ AC_MSG_RESULT([$attr_name])
+ if test "$attr_name" != PTHREAD_CREATE_JOINABLE; then
+ AC_DEFINE_UNQUOTED([PTHREAD_CREATE_JOINABLE], [$attr_name],
+ [Define to necessary symbol if this constant
+ uses a non-standard name on your system.])
+ fi
+
+ AC_MSG_CHECKING([if more special flags are required for pthreads])
+ flag=no
+ case ${host_os} in
+ aix* | freebsd* | darwin*) flag="-D_THREAD_SAFE";;
+ osf* | hpux*) flag="-D_REENTRANT";;
+ solaris*)
+ if test "$GCC" = "yes"; then
+ flag="-D_REENTRANT"
+ else
+ # TODO: What about Clang on Solaris?
+ flag="-mt -D_REENTRANT"
+ fi
+ ;;
+ esac
+ AC_MSG_RESULT([$flag])
+ if test "x$flag" != xno; then
+ PTHREAD_CFLAGS="$flag $PTHREAD_CFLAGS"
+ fi
+
+ AC_CACHE_CHECK([for PTHREAD_PRIO_INHERIT],
+ [ax_cv_PTHREAD_PRIO_INHERIT], [
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <pthread.h>]],
+ [[int i = PTHREAD_PRIO_INHERIT;]])],
+ [ax_cv_PTHREAD_PRIO_INHERIT=yes],
+ [ax_cv_PTHREAD_PRIO_INHERIT=no])
+ ])
+ AS_IF([test "x$ax_cv_PTHREAD_PRIO_INHERIT" = "xyes"],
+ [AC_DEFINE([HAVE_PTHREAD_PRIO_INHERIT], [1], [Have PTHREAD_PRIO_INHERIT.])])
+
+ LIBS="$save_LIBS"
+ CFLAGS="$save_CFLAGS"
+
+ # More AIX lossage: compile with *_r variant
+ if test "x$GCC" != xyes; then
+ case $host_os in
+ aix*)
+ AS_CASE(["x/$CC"],
+ [x*/c89|x*/c89_128|x*/c99|x*/c99_128|x*/cc|x*/cc128|x*/xlc|x*/xlc_v6|x*/xlc128|x*/xlc128_v6],
+ [#handle absolute path differently from PATH based program lookup
+ AS_CASE(["x$CC"],
+ [x/*],
+ [AS_IF([AS_EXECUTABLE_P([${CC}_r])],[PTHREAD_CC="${CC}_r"])],
+ [AC_CHECK_PROGS([PTHREAD_CC],[${CC}_r],[$CC])])])
+ ;;
+ esac
+ fi
+fi
+
+test -n "$PTHREAD_CC" || PTHREAD_CC="$CC"
+
+AC_SUBST([PTHREAD_LIBS])
+AC_SUBST([PTHREAD_CFLAGS])
+AC_SUBST([PTHREAD_CC])
+
+# Finally, execute ACTION-IF-FOUND/ACTION-IF-NOT-FOUND:
+if test x"$ax_pthread_ok" = xyes; then
+ ifelse([$1],,[AC_DEFINE([HAVE_PTHREAD],[1],[Define if you have POSIX threads libraries and header files.])],[$1])
+ :
+else
+ ax_pthread_ok=no
+ $2
+fi
+AC_LANG_POP
+])dnl AX_PTHREAD
diff --git a/configure b/configure
index 3cf2096..e5bfa22 100755
--- a/configure
+++ b/configure
@@ -656,7 +656,8 @@ LDAP_LIBS_BE
LDAP_LIBS_FE
PTHREAD_CFLAGS
PTHREAD_LIBS
-acx_pthread_config
+PTHREAD_CC
+ax_pthread_config
have_win32_dbghelp
HAVE_IPV6
LIBOBJS
@@ -12506,7 +12507,7 @@ ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
ac_compiler_gnu=$ac_cv_c_compiler_gnu
-acx_pthread_ok=no
+ax_pthread_ok=no
# We used to check for pthread.h first, but this fails if pthread.h
# requires special compiler flags (e.g. on True64 or Sequent).
@@ -12541,13 +12542,13 @@ return pthread_join ();
}
_ACEOF
if ac_fn_c_try_link "$LINENO"; then :
- acx_pthread_ok=yes
+ ax_pthread_ok=yes
fi
rm -f core conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $acx_pthread_ok" >&5
-$as_echo "$acx_pthread_ok" >&6; }
- if test x"$acx_pthread_ok" = xno; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_pthread_ok" >&5
+$as_echo "$ax_pthread_ok" >&6; }
+ if test x"$ax_pthread_ok" = xno; then
PTHREAD_LIBS=""
PTHREAD_CFLAGS=""
fi
@@ -12565,7 +12566,7 @@ fi
# which indicates that we try without any flags at all, and "pthread-config"
# which is a program returning the flags for the Pth emulation library.
-acx_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config pthreadGC2"
+ax_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config"
# The ordering *is* (sometimes) important. Some notes on the
# individual items follow:
@@ -12582,30 +12583,64 @@ acx_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -m
# -mt: Sun Workshop C (may only link SunOS threads [-lthread], but it
# doesn't hurt to check since this sometimes defines pthreads too;
# also defines -D_REENTRANT)
+# ... -mt is also the pthreads flag for HP/aCC
# pthread: Linux, etcetera
# --thread-safe: KAI C++
# pthread-config: use pthread-config program (for GNU Pth library)
-case "${host_cpu}-${host_os}" in
- *solaris*)
+case ${host_os} in
+ solaris*)
# On Solaris (at least, for some versions), libc contains stubbed
# (non-functional) versions of the pthreads routines, so link-based
- # tests will erroneously succeed. (We need to link with -pthread or
+ # tests will erroneously succeed. (We need to link with -pthreads/-mt/
# -lpthread.) (The stubs are missing pthread_cleanup_push, or rather
# a function called by this macro, so we could check for that, but
# who knows whether they'll stub that too in a future libc.) So,
# we'll just look for -pthreads and -lpthread first:
- acx_pthread_flags="-pthread -pthreads pthread -mt $acx_pthread_flags"
+ ax_pthread_flags="-pthreads pthread -mt -pthread $ax_pthread_flags"
+ ;;
+
+ darwin*)
+ ax_pthread_flags="-pthread $ax_pthread_flags"
;;
esac
-if test x"$acx_pthread_ok" = xno; then
-for flag in $acx_pthread_flags; do
+# Clang doesn't consider unrecognized options an error unless we specify
+# -Werror. We throw in some extra Clang-specific options to ensure that
+# this doesn't happen for GCC, which also accepts -Werror.
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if compiler needs -Werror to reject unknown flags" >&5
+$as_echo_n "checking if compiler needs -Werror to reject unknown flags... " >&6; }
+save_CFLAGS="$CFLAGS"
+ax_pthread_extra_flags="-Werror"
+CFLAGS="$CFLAGS $ax_pthread_extra_flags -Wunknown-warning-option -Wsizeof-array-argument"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+int foo(void);
+int
+main ()
+{
+foo()
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
+$as_echo "yes" >&6; }
+else
+ ax_pthread_extra_flags=
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+CFLAGS="$save_CFLAGS"
+
+if test x"$ax_pthread_ok" = xno; then
+for flag in $ax_pthread_flags; do
- tryPTHREAD_CFLAGS=""
- tryPTHREAD_LIBS=""
case $flag in
none)
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether pthreads work without any flags" >&5
@@ -12615,21 +12650,19 @@ $as_echo_n "checking whether pthreads work without any flags... " >&6; }
-*)
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether pthreads work with $flag" >&5
$as_echo_n "checking whether pthreads work with $flag... " >&6; }
- tryPTHREAD_CFLAGS="$flag"
+ PTHREAD_CFLAGS="$flag"
;;
pthread-config)
- # skip this if we already have flags defined, for PostgreSQL
- if test x"$PTHREAD_CFLAGS" != x -o x"$PTHREAD_LIBS" != x; then continue; fi
# Extract the first word of "pthread-config", so it can be a program name with args.
set dummy pthread-config; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
$as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_acx_pthread_config+:} false; then :
+if ${ac_cv_prog_ax_pthread_config+:} false; then :
$as_echo_n "(cached) " >&6
else
- if test -n "$acx_pthread_config"; then
- ac_cv_prog_acx_pthread_config="$acx_pthread_config" # Let the user override the test.
+ if test -n "$ax_pthread_config"; then
+ ac_cv_prog_ax_pthread_config="$ax_pthread_config" # Let the user override the test.
else
as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
@@ -12638,7 +12671,7 @@ do
test -z "$as_dir" && as_dir=.
for ac_exec_ext in '' $ac_executable_extensions; do
if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
- ac_cv_prog_acx_pthread_config="yes"
+ ac_cv_prog_ax_pthread_config="yes"
$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
break 2
fi
@@ -12646,35 +12679,35 @@ done
done
IFS=$as_save_IFS
- test -z "$ac_cv_prog_acx_pthread_config" && ac_cv_prog_acx_pthread_config="no"
+ test -z "$ac_cv_prog_ax_pthread_config" && ac_cv_prog_ax_pthread_config="no"
fi
fi
-acx_pthread_config=$ac_cv_prog_acx_pthread_config
-if test -n "$acx_pthread_config"; then
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $acx_pthread_config" >&5
-$as_echo "$acx_pthread_config" >&6; }
+ax_pthread_config=$ac_cv_prog_ax_pthread_config
+if test -n "$ax_pthread_config"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_pthread_config" >&5
+$as_echo "$ax_pthread_config" >&6; }
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
$as_echo "no" >&6; }
fi
- if test x"$acx_pthread_config" = xno; then continue; fi
- tryPTHREAD_CFLAGS="`pthread-config --cflags`"
- tryPTHREAD_LIBS="`pthread-config --ldflags` `pthread-config --libs`"
+ if test x"$ax_pthread_config" = xno; then continue; fi
+ PTHREAD_CFLAGS="`pthread-config --cflags`"
+ PTHREAD_LIBS="`pthread-config --ldflags` `pthread-config --libs`"
;;
*)
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for the pthreads library -l$flag" >&5
$as_echo_n "checking for the pthreads library -l$flag... " >&6; }
- tryPTHREAD_LIBS="-l$flag"
+ PTHREAD_LIBS="-l$flag"
;;
esac
save_LIBS="$LIBS"
save_CFLAGS="$CFLAGS"
- LIBS="$tryPTHREAD_LIBS $PTHREAD_LIBS $LIBS"
- CFLAGS="$CFLAGS $PTHREAD_CFLAGS $tryPTHREAD_CFLAGS"
+ LIBS="$PTHREAD_LIBS $LIBS"
+ CFLAGS="$CFLAGS $PTHREAD_CFLAGS $ax_pthread_extra_flags"
# Check for various functions. We must include pthread.h,
# since some functions may be macros. (On the Sequent, we
@@ -12688,64 +12721,219 @@ $as_echo_n "checking for the pthreads library -l$flag... " >&6; }
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
#include <pthread.h>
+ static void routine(void *a) { a = 0; }
+ static void *start_routine(void *a) { return a; }
int
main ()
{
-pthread_t th; pthread_join(th, 0);
- pthread_attr_init(0); pthread_cleanup_push(0, 0);
- pthread_create(0,0,0,0); pthread_cleanup_pop(0);
+pthread_t th; pthread_attr_t attr;
+ pthread_create(&th, 0, start_routine, 0);
+ pthread_join(th, 0);
+ pthread_attr_init(&attr);
+ pthread_cleanup_push(routine, 0);
+ pthread_cleanup_pop(0) /* ; */
;
return 0;
}
_ACEOF
if ac_fn_c_try_link "$LINENO"; then :
- acx_pthread_ok=yes
-else
- acx_pthread_ok=no
+ ax_pthread_ok=yes
fi
rm -f core conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext
- if test "x$acx_pthread_ok" = xyes; then
- # Don't use options that are ignored by the compiler.
- # We find them by checking stderror.
- cat >conftest.$ac_ext <<_ACEOF
+ LIBS="$save_LIBS"
+ CFLAGS="$save_CFLAGS"
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_pthread_ok" >&5
+$as_echo "$ax_pthread_ok" >&6; }
+ if test "x$ax_pthread_ok" = xyes; then
+ break;
+ fi
+
+ PTHREAD_LIBS=""
+ PTHREAD_CFLAGS=""
+done
+fi
+
+# Various other checks:
+if test "x$ax_pthread_ok" = xyes; then
+ save_LIBS="$LIBS"
+ LIBS="$PTHREAD_LIBS $LIBS"
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+
+ # Detect AIX lossage: JOINABLE attribute is called UNDETACHED.
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for joinable pthread attribute" >&5
+$as_echo_n "checking for joinable pthread attribute... " >&6; }
+ attr_name=unknown
+ for attr in PTHREAD_CREATE_JOINABLE PTHREAD_CREATE_UNDETACHED; do
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+#include <pthread.h>
int
-main (int argc, char **argv)
+main ()
{
- (void) argc;
- (void) argv;
+int attr = $attr; return attr /* ; */
+ ;
return 0;
}
_ACEOF
- rm -f conftest.$ac_objext conftest$ac_exeext
- # Check both linking and compiling, because they might tolerate different options.
- if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval $ac_compile 2>&1 1>&5)`" = ""; then
- # The original macro breaks out of the loop at this point,
- # but we continue trying flags because Linux needs -lpthread
- # too to build libpq successfully. The test above only
- # tests for building binaries, not shared libraries.
- PTHREAD_LIBS=" $tryPTHREAD_LIBS $PTHREAD_LIBS"
- PTHREAD_CFLAGS="$PTHREAD_CFLAGS $tryPTHREAD_CFLAGS"
- else acx_pthread_ok=no
+if ac_fn_c_try_link "$LINENO"; then :
+ attr_name=$attr; break
+fi
+rm -f core conftest.err conftest.$ac_objext \
+ conftest$ac_exeext conftest.$ac_ext
+ done
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $attr_name" >&5
+$as_echo "$attr_name" >&6; }
+ if test "$attr_name" != PTHREAD_CREATE_JOINABLE; then
+
+cat >>confdefs.h <<_ACEOF
+#define PTHREAD_CREATE_JOINABLE $attr_name
+_ACEOF
+
+ fi
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking if more special flags are required for pthreads" >&5
+$as_echo_n "checking if more special flags are required for pthreads... " >&6; }
+ flag=no
+ case ${host_os} in
+ aix* | freebsd* | darwin*) flag="-D_THREAD_SAFE";;
+ osf* | hpux*) flag="-D_REENTRANT";;
+ solaris*)
+ if test "$GCC" = "yes"; then
+ flag="-D_REENTRANT"
+ else
+ # TODO: What about Clang on Solaris?
+ flag="-mt -D_REENTRANT"
fi
+ ;;
+ esac
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $flag" >&5
+$as_echo "$flag" >&6; }
+ if test "x$flag" != xno; then
+ PTHREAD_CFLAGS="$flag $PTHREAD_CFLAGS"
fi
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for PTHREAD_PRIO_INHERIT" >&5
+$as_echo_n "checking for PTHREAD_PRIO_INHERIT... " >&6; }
+if ${ax_cv_PTHREAD_PRIO_INHERIT+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+#include <pthread.h>
+int
+main ()
+{
+int i = PTHREAD_PRIO_INHERIT;
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+ ax_cv_PTHREAD_PRIO_INHERIT=yes
+else
+ ax_cv_PTHREAD_PRIO_INHERIT=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+ conftest$ac_exeext conftest.$ac_ext
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_PTHREAD_PRIO_INHERIT" >&5
+$as_echo "$ax_cv_PTHREAD_PRIO_INHERIT" >&6; }
+ if test "x$ax_cv_PTHREAD_PRIO_INHERIT" = "xyes"; then :
+
+$as_echo "#define HAVE_PTHREAD_PRIO_INHERIT 1" >>confdefs.h
+
+fi
+
LIBS="$save_LIBS"
CFLAGS="$save_CFLAGS"
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $acx_pthread_ok" >&5
-$as_echo "$acx_pthread_ok" >&6; }
+ # More AIX lossage: compile with *_r variant
+ if test "x$GCC" != xyes; then
+ case $host_os in
+ aix*)
+ case "x/$CC" in #(
+ x*/c89|x*/c89_128|x*/c99|x*/c99_128|x*/cc|x*/cc128|x*/xlc|x*/xlc_v6|x*/xlc128|x*/xlc128_v6) :
+ #handle absolute path differently from PATH based program lookup
+ case "x$CC" in #(
+ x/*) :
+ if as_fn_executable_p ${CC}_r; then :
+ PTHREAD_CC="${CC}_r"
+fi ;; #(
+ *) :
+ for ac_prog in ${CC}_r
+do
+ # Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_PTHREAD_CC+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ if test -n "$PTHREAD_CC"; then
+ ac_cv_prog_PTHREAD_CC="$PTHREAD_CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+ IFS=$as_save_IFS
+ test -z "$as_dir" && as_dir=.
+ for ac_exec_ext in '' $ac_executable_extensions; do
+ if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ ac_cv_prog_PTHREAD_CC="$ac_prog"
+ $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+ break 2
+ fi
+done
+ done
+IFS=$as_save_IFS
+
+fi
+fi
+PTHREAD_CC=$ac_cv_prog_PTHREAD_CC
+if test -n "$PTHREAD_CC"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $PTHREAD_CC" >&5
+$as_echo "$PTHREAD_CC" >&6; }
+else
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+ test -n "$PTHREAD_CC" && break
done
+test -n "$PTHREAD_CC" || PTHREAD_CC="$CC"
+ ;;
+esac ;; #(
+ *) :
+ ;;
+esac
+ ;;
+ esac
+ fi
fi
-# The original macro has a bunch of other tests here, which we have removed
-# because (a) Postgres doesn't need them, and (b) $acx_pthread_ok is not
-# meaningful at this point.
+test -n "$PTHREAD_CC" || PTHREAD_CC="$CC"
+
+
+
+# Finally, execute ACTION-IF-FOUND/ACTION-IF-NOT-FOUND:
+if test x"$ax_pthread_ok" = xyes; then
+$as_echo "#define HAVE_PTHREAD 1" >>confdefs.h
+ :
+else
+ ax_pthread_ok=no
+
+fi
ac_ext=c
ac_cpp='$CPP $CPPFLAGS'
ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
diff --git a/configure.in b/configure.in
index 8f8ed69..81ce612 100644
--- a/configure.in
+++ b/configure.in
@@ -1579,7 +1579,7 @@ fi
# See the comment at the top of src/port/thread.c for more information.
# WIN32 doesn't need the pthread tests; it always uses threads
if test "$enable_thread_safety" = yes -a "$PORTNAME" != "win32"; then
-ACX_PTHREAD # set thread flags
+AX_PTHREAD # set thread flags
# Some platforms use these, so just define them. They can't hurt if they
# are not supported. For example, on Solaris -D_POSIX_PTHREAD_SEMANTICS
--
2.1.4
Heikki Linnakangas <hlinnaka@iki.fi> writes:
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.
OK ...
Then we can
also remove the test for whether the compiler produces any warnings.
Don't see how that follows?
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.
It definitely *would* be nice to get back in sync with the upstream
version of that file. But I'm unconvinced about the warnings angle.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/08/2015 04:38 PM, Tom Lane wrote:
Heikki Linnakangas <hlinnaka@iki.fi> writes:
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.OK ...
Then we can
also remove the test for whether the compiler produces any warnings.Don't see how that follows?
That test was added after the GCC-bug workaround, because that
workaround caused warnings. The upstream philosophy is to have a list of
flags, and try them in order until you find one that works. With the
workaround that we added, after it finds one flag that makes the pthread
test program to compile, it adds every flag in the list to the command
line as long as they donn't make the test program to fail again. For
example, after it found out that "-pthread" makes the compilation to
work, it appended "-pthreads -mthreads -mt -lpthread --thread-safe" to
PTHREAD_CFLAGS, as long as none of those caused a compiler error. They
could cause warnings though. That's why we had to add the test to check
for warnings.
The only scenario where you might now get warnings if we switch to
upstream version, and didn't before, is if one of the flags makes
pthreads to work, but also creates compiler warnings, while another flag
later in the list would make it work without warnings. That's not
totally inconceivable, but I doubt it happens. In any case, there's
nothing PostgreSQL-specific about that, so if that happens, I'd like to
find out so that we can complain to the upstream.
I'll commit the upstream version, and we'll see what the buildfarm thinks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes:
The only scenario where you might now get warnings if we switch to
upstream version, and didn't before, is if one of the flags makes
pthreads to work, but also creates compiler warnings, while another flag
later in the list would make it work without warnings. That's not
totally inconceivable, but I doubt it happens. In any case, there's
nothing PostgreSQL-specific about that, so if that happens, I'd like to
find out so that we can complain to the upstream.
Actually, it looks like the modern version of ax_pthread.m4 adds -Werror
while testing, so that this should not be an issue anyway (at least on
compilers that accept -Werror).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/08/2015 08:50 PM, Tom Lane wrote:
Heikki Linnakangas <hlinnaka@iki.fi> writes:
The only scenario where you might now get warnings if we switch to
upstream version, and didn't before, is if one of the flags makes
pthreads to work, but also creates compiler warnings, while another flag
later in the list would make it work without warnings. That's not
totally inconceivable, but I doubt it happens. In any case, there's
nothing PostgreSQL-specific about that, so if that happens, I'd like to
find out so that we can complain to the upstream.Actually, it looks like the modern version of ax_pthread.m4 adds -Werror
while testing, so that this should not be an issue anyway (at least on
compilers that accept -Werror).
To conclude this thread: I replaced our custom pthread-checking autoconf
macro with the latest upstream version, in PostgreSQL master. That
should fix your original problem with the uClibc, OpenSSL, and pthreads
combination, in PostgreSQL master (i.e. the future 9.6 version).
As a workaround for current versions, you can give
PTHREAD_CFLAGS=-pthread (or whatever the right flag for that platform
is) explicitly on the configure command line. That way the autoconf
script will only test if that option works, skipping the autodetection
logic and the warnings-test, so it will pass.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers