Re: [HACKERS] configure can't detect proper pthread flags
On Thu, Apr 30, 2015 at 3:51 PM, Robert Haas wrote: > On Wed, Apr 8, 2015 at 2:31 AM, Max Filippov wrote: >> On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov wrote: >>> On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov 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-jcmvb...@gmail.com >> >> Ping? >> 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
Re: [HACKERS] configure can't detect proper pthread flags
On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov wrote: > On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov 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-jcmvb...@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
Re: [HACKERS] configure can't detect proper pthread flags
On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov 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-jcmvb...@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
[HACKERS] [PATCH] Compare linker/compiler output with their default output
linker and compiler may have noisy output by default, making
acx_pthread.m4 believe that pthread options that it tries are ignored
as invalid.
Record default compiler and linker output and see if adding pthread
option changes that, instead of assuming that linker and compiler are
silent by default.
Signed-off-by: Max Filippov
---
config/acx_pthread.m4 | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/config/acx_pthread.m4 b/config/acx_pthread.m4
index 581164b..028fdb1 100644
--- a/config/acx_pthread.m4
+++ b/config/acx_pthread.m4
@@ -79,6 +79,22 @@ case "${host_cpu}-${host_os}" in
esac
if test x"$acx_pthread_ok" = xno; then
+
+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
+
+# Record the default linker and compiler output
+ld_default_output="`(eval $ac_link 2>&1 1>&5)`"
+cc_default_output="`(eval $ac_compile 2>&1 1>&5)`"
+
for flag in $acx_pthread_flags; do
tryPTHREAD_CFLAGS=""
@@ -142,7 +158,7 @@ main (int argc, char **argv)
_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
+if test "`(eval $ac_link 2>&1 1>&5)`" = "$ld_default_output" &&
test "`(eval $ac_compile 2>&1 1>&5)`" = "$cc_default_output"; 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
--
1.8.1.4
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] configure can't detect proper pthread flags
On Fri, Mar 20, 2015 at 3:05 PM, Robert Haas wrote: > On Fri, Mar 20, 2015 at 7:01 AM, Max Filippov wrote: >> On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane 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
Re: [HACKERS] configure can't detect proper pthread flags
On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane 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
Re: [HACKERS] configure can't detect proper pthread flags
On Fri, Mar 20, 2015 at 5:20 AM, Andrew Gierth wrote: >>>>>> "Max" == Max Filippov 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
Re: [HACKERS] configure can't detect proper pthread flags
On Fri, Mar 20, 2015 at 5:09 AM, Bruce Momjian 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 -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. > > 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
Re: [HACKERS] configure can't detect proper pthread flags
Hi Tom, On Fri, Mar 20, 2015 at 3:50 AM, Tom Lane wrote: > Max Filippov 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. 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
[HACKERS] 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] 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
