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