The bug: if you don't pass an --enable-shared option to configure, and
build from the deps tarball, neon gets configured with
--disable-shared. On Linux, the build seems to succeed anyway (I
guess you can build shared libraries against static ones) but on
Solaris the build fails as a result.
The cause: If you look at the configure script, you'll see:
[... gobs of stuff ...]
# The arguments passed to this configure script are passed
# down to neon's configure script, but, since neon
# defaults to *not* building shared libs, and we default
# to building shared libs, we have to explicitly pass down
# an --{enable,disable}-shared argument, to make sure neon
# does the same as we do.
if test "$enable_shared" = "yes"; then
args="--enable-shared"
else
args="--disable-shared"
fi
[... more gobs of stuff ...]
if test "${enable_shared+set}" = set; then
[... stuff ...]
else
enable_shared=yes
fi
[... and the rest of the script ...]
Obviously, there is an ordering problem here. enable_shared doesn't
receive its default value until well after the neon configure goop
checks it with the assumption that the default has been set.
The workaround: Pass --enable-shared when configuring with the deps
tarball.
The fix: build/ac-macros/neon.m4 could check if enable_shared is not
no, instead of checking if it's yes. Or the libtool goop could be
moved above the neon goop in configure.ac. I'm not prepared to test
either option at this time.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1048352
Received on 2009-01-25 05:00:52 CET