Re: [HACKERS] pg_crypto failures with llvm on OSX
On sön, 2012-03-11 at 00:34 -0500, Tom Lane wrote: I think it'd be useful to print CPPFLAGS, CFLAGS, and LDFLAGS if the environment is supplying values for them (or maybe print their values after absorbing whatever is in the buildfarm animal's config). Peter might know whether there's anything else of great interest. The ones that we have designated as pertinent are listed at the bottom of configure --help. But you can actually see the values that these had in the environment by looking in config.log under ac_cv_env_*. -- 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] pg_crypto failures with llvm on OSX
On 03/11/2012 08:00 AM, Peter Eisentraut wrote: On sön, 2012-03-11 at 00:34 -0500, Tom Lane wrote: I think it'd be useful to print CPPFLAGS, CFLAGS, and LDFLAGS if the environment is supplying values for them (or maybe print their values after absorbing whatever is in the buildfarm animal's config). Peter might know whether there's anything else of great interest. The ones that we have designated as pertinent are listed at the bottom of configure --help. But you can actually see the values that these had in the environment by looking in config.log under ac_cv_env_*. Yeah, so there's nothing really to do here. And in the case of the failures we saw, nothing was set, so Tom's analysis of the failure coming from Macports libxml2 looks correct. cheers andrew -- 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] pg_crypto failures with llvm on OSX
On 03/09/2012 07:50 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be getting consistent warnings when running the pgcrypto regression tests, that look like this: WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58 Does anyone have an idea why that might be? Worksforme, on an up-to-date Lion system using exactly the same compiler version. I do see the deprecation warnings (which Apple seems to have plastered on every single OpenSSL function ... doesn't leave me with a warm feeling about their future plans). I suspect that mussel has an ABI-incompatible openssl library hanging around someplace. On my machine otool -L pgcrypto.so shows /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0) It'd be interesting to know what it says on mussel. Robert, please investigate. cheers andrew -- 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] pg_crypto failures with llvm on OSX
On Mar 10, 2012, at 4:19 PM, Andrew Dunstan and...@dunslane.net wrote: On 03/09/2012 07:50 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be getting consistent warnings when running the pgcrypto regression tests, that look like this: WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58 Does anyone have an idea why that might be? Worksforme, on an up-to-date Lion system using exactly the same compiler version. I do see the deprecation warnings (which Apple seems to have plastered on every single OpenSSL function ... doesn't leave me with a warm feeling about their future plans). I suspect that mussel has an ABI-incompatible openssl library hanging around someplace. On my machine otool -L pgcrypto.so shows /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0) It'd be interesting to know what it says on mussel. Robert, please investigate. creagers-imac:pgcrypto Robert$ otool -L pgcrypto.so pgcrypto.so: /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) via Mac Ports cheers andrew -- 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] pg_crypto failures with llvm on OSX
Robert Creager rob...@logicalchaos.org writes: On Mar 10, 2012, at 4:19 PM, Andrew Dunstan and...@dunslane.net wrote: On 03/09/2012 07:50 PM, Tom Lane wrote: I suspect that mussel has an ABI-incompatible openssl library hanging around someplace. On my machine otool -L pgcrypto.so shows /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0) It'd be interesting to know what it says on mussel. creagers-imac:pgcrypto Robert$ otool -L pgcrypto.so pgcrypto.so: /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) Uh-huh. I will bet a good deal that you are compiling against the Apple-supplied openssl header files, but then linking against the MacPorts openssl shlib, which evidently is configured a bit differently than Apple's copy. [ pokes around in the mussel build logs ] I see -L/opt/local/lib in the link commands, which explains why you're linking to that shlib, and I don't see anything like -I/opt/local/include, which is probably needed to find the matching header files. There is a -I/opt/local/include/libxml2, but that isn't going to help unless your /opt/local layout is really weird. What's really odd though is that there is nothing in the configuration script that injects any of those switches. I think you've got some screwy global configuration on that machine, which you'd be well advised to try to get rid of --- it's tough for people to do remote diagnosis of buildfarm critters when there's relevant configuration that's not exposed in the config script. 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
Re: [HACKERS] pg_crypto failures with llvm on OSX
On Mar 10, 2012, at 5:01 PM, Tom Lane t...@sss.pgh.pa.us wrote: What's really odd though is that there is nothing in the configuration script that injects any of those switches. I think you've got some screwy global configuration on that machine, which you'd be well advised to try to get rid of --- it's tough for people to do remote diagnosis of buildfarm critters when there's relevant configuration that's not exposed in the config script. No global config. Changed the path around to have /opt/local after the standard Apple ones, and it appears to be working fine. autoconf must be throwing in that path based on executables found? Later, Rob -- 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] pg_crypto failures with llvm on OSX
Robert Creager rob...@logicalchaos.org writes: On Mar 10, 2012, at 5:01 PM, Tom Lane t...@sss.pgh.pa.us wrote: What's really odd though is that there is nothing in the configuration script that injects any of those switches. I think you've got some screwy global configuration on that machine, which you'd be well advised to try to get rid of --- it's tough for people to do remote diagnosis of buildfarm critters when there's relevant configuration that's not exposed in the config script. No global config. Changed the path around to have /opt/local after the standard Apple ones, and it appears to be working fine. autoconf must be throwing in that path based on executables found? I don't believe autoconf would insert such stuff on its own authority. I'm wondering about CPPFLAGS, CFLAGS, LDFLAGS or similar variables being set in the environment that the buildfarm script is running in. Take a look at ~/.bash_profile and suchlike files. (I wonder whether it'd be a good idea for the buildfarm script to explicitly clear anything that autoconf pays attention to from its startup environment, so that you have to set these variables in the buildfarm config to make them have effect. If not that, maybe print env output to document what the situation is?) 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
Re: [HACKERS] pg_crypto failures with llvm on OSX
On Mar 10, 2012, at 7:15 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Creager rob...@logicalchaos.org writes: On Mar 10, 2012, at 5:01 PM, Tom Lane t...@sss.pgh.pa.us wrote: What's really odd though is that there is nothing in the configuration script that injects any of those switches. I think you've got some screwy global configuration on that machine, which you'd be well advised to try to get rid of --- it's tough for people to do remote diagnosis of buildfarm critters when there's relevant configuration that's not exposed in the config script. No global config. Changed the path around to have /opt/local after the standard Apple ones, and it appears to be working fine. autoconf must be throwing in that path based on executables found? I don't believe autoconf would insert such stuff on its own authority. I'm wondering about CPPFLAGS, CFLAGS, LDFLAGS or similar variables being set in the environment that the buildfarm script is running in. Take a look at ~/.bash_profile and suchlike files. Nope. Only PATH is set. Later, Rob -- 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] pg_crypto failures with llvm on OSX
On 03/10/2012 09:15 PM, Tom Lane wrote: (I wonder whether it'd be a good idea for the buildfarm script to explicitly clear anything that autoconf pays attention to from its startup environment, so that you have to set these variables in the buildfarm config to make them have effect. If not that, maybe print env output to document what the situation is?) I can put the latter in the next client release, unless people think it's a bit insecure to report arbitrary environment values. If we were to clear them, which would we clear? cheers andrew -- 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] pg_crypto failures with llvm on OSX
On Mar 10, 2012, at 7:54 PM, Andrew Dunstan and...@dunslane.net wrote: On 03/10/2012 09:15 PM, Tom Lane wrote: (I wonder whether it'd be a good idea for the buildfarm script to explicitly clear anything that autoconf pays attention to from its startup environment, so that you have to set these variables in the buildfarm config to make them have effect. If not that, maybe print env output to document what the situation is?) I can put the latter in the next client release, unless people think it's a bit insecure to report arbitrary environment values. If we were to clear them, which would we clear? Why it just report the pertinent ones? Rob -- 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] pg_crypto failures with llvm on OSX
Robert Creager rob...@logicalchaos.org writes: On Mar 10, 2012, at 7:15 PM, Tom Lane t...@sss.pgh.pa.us wrote: I don't believe autoconf would insert such stuff on its own authority. I'm wondering about CPPFLAGS, CFLAGS, LDFLAGS or similar variables being set in the environment that the buildfarm script is running in. Take a look at ~/.bash_profile and suchlike files. Nope. Only PATH is set. Hmm ... [ eyeballs the mussel build reports some more ] ... ah-hah, look at this (at the bottom of the configure step for the last failed build): configure: using CPPFLAGS= -I/opt/local/include/libxml2 configure: using LDFLAGS= -L/opt/local/lib -Wl,-dead_strip_dylibs versus this in the first successful build: configure: using CPPFLAGS= -I/usr/include/libxml2 configure: using LDFLAGS= -Wl,-dead_strip_dylibs I will bet that those -I and -L switches are coming from this part of configure.in: if test $with_libxml = yes ; then AC_CHECK_PROGS(XML2_CONFIG, xml2-config) if test -n $XML2_CONFIG; then for pgac_option in `$XML2_CONFIG --cflags`; do case $pgac_option in -I*|-D*) CPPFLAGS=$CPPFLAGS $pgac_option;; esac done for pgac_option in `$XML2_CONFIG --libs`; do case $pgac_option in -L*) LDFLAGS=$LDFLAGS $pgac_option;; esac done fi fi So the answer is that you've got a MacPorts libxml2 installation whose xml2-config program inserts these not terribly self-consistent switches, resulting in drive-by failure of the openssl configuration. When you switched your PATH around, instead of finding the MacPorts copy of xml2-config, configure found the one in /usr/bin, which provides -I/usr/include/libxml2 and no particular -L switch; hence no openssl problem. You're building with a different libxml2 than you were before, though. Seems to me this is a MacPorts bug: their libxml2 and openssl packagings don't play nice together. 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
Re: [HACKERS] pg_crypto failures with llvm on OSX
Andrew Dunstan and...@dunslane.net writes: On 03/10/2012 09:15 PM, Tom Lane wrote: (I wonder whether it'd be a good idea for the buildfarm script to explicitly clear anything that autoconf pays attention to from its startup environment, so that you have to set these variables in the buildfarm config to make them have effect. If not that, maybe print env output to document what the situation is?) I can put the latter in the next client release, unless people think it's a bit insecure to report arbitrary environment values. If we were to clear them, which would we clear? I think it'd be useful to print CPPFLAGS, CFLAGS, and LDFLAGS if the environment is supplying values for them (or maybe print their values after absorbing whatever is in the buildfarm animal's config). Peter might know whether there's anything else of great interest. 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
[HACKERS] pg_crypto failures with llvm on OSX
Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be getting consistent warnings when running the pgcrypto regression tests, that look like this: WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58 Does anyone have an idea why that might be? cheers andrew -- 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] pg_crypto failures with llvm on OSX
On Fri, Mar 09, 2012 at 05:28:20PM -0500, Andrew Dunstan wrote: Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be getting consistent warnings when running the pgcrypto regression tests, that look like this: WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58 Does anyone have an idea why that might be? Could it be related to this: openssl.c:840: warning: AES_cbc_encrypt is deprecated (declared at /usr/include/openssl/aes.h:106) basically every API under /usr/include/openssl gives this warning. Replaced or heavily hacked openssl library? Same for core code: be-secure.c:329: warning: SSL_renegotiate is deprecated (declared at /usr/include/openssl/ssl.h:1530) Could someone take a look whats going on there? -- marko -- 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] pg_crypto failures with llvm on OSX
Andrew Dunstan and...@dunslane.net writes: Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be getting consistent warnings when running the pgcrypto regression tests, that look like this: WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58 Does anyone have an idea why that might be? Worksforme, on an up-to-date Lion system using exactly the same compiler version. I do see the deprecation warnings (which Apple seems to have plastered on every single OpenSSL function ... doesn't leave me with a warm feeling about their future plans). I suspect that mussel has an ABI-incompatible openssl library hanging around someplace. On my machine otool -L pgcrypto.so shows /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0) It'd be interesting to know what it says on mussel. 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
