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
