Re: pg_crypto failures with llvm on OSX

Robert Creager <robert(at)logicalchaos(dot)org> writes:
> On Mar 10, 2012, at 7:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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