Thread: 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
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
Andrew Dunstan <andrew@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
On 03/09/2012 07:50 PM, Tom Lane wrote: > Andrew Dunstan<andrew@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
On Mar 10, 2012, at 4:19 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > > On 03/09/2012 07:50 PM, Tom Lane wrote: >> Andrew Dunstan<andrew@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 (compatibilityversion 1.0.0, current version 159.1.0) via Mac Ports > > cheers > > andrew >
Robert Creager <robert@logicalchaos.org> writes:
> On Mar 10, 2012, at 4:19 PM, Andrew Dunstan <andrew@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
On Mar 10, 2012, at 5:01 PM, Tom Lane <tgl@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 workingfine. autoconf must be throwing in that path based on executables found? Later, Rob
Robert Creager <robert@logicalchaos.org> writes:
> On Mar 10, 2012, at 5:01 PM, Tom Lane <tgl@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
workingfine. 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
On Mar 10, 2012, at 7:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Creager <robert@logicalchaos.org> writes: >> On Mar 10, 2012, at 5:01 PM, Tom Lane <tgl@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 workingfine. 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
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
On Mar 10, 2012, at 7:54 PM, Andrew Dunstan <andrew@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 environmentvalues. If we were to clear them, which would we clear? Why it just report the pertinent ones? Rob
Robert Creager <robert@logicalchaos.org> writes:
> On Mar 10, 2012, at 7:15 PM, Tom Lane <tgl@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_optionin `$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
Andrew Dunstan <andrew@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
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_*.
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