You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/07/15 17:31:23 UTC
Build error with bundled apr-util and neon
After upgrading neon to 0.24.7 today, I found I could not build
Subversion on my RHEL 3 machine:
make[2]: Entering directory `/me/svn/neon/src'
/bin/sh ../libtool [stuff] /me/svn/apr-util/xml/expat/lib/libexpat.la
libtool: link: cannot find the library `/me/svn/apr-util/xml/expat/lib/libexpat.la'
apr-util apparently did not build its internal expat because it found
a system one. The culprit seems to be a bad assumption in neon.m4:
# If we have apr-util and it's bundled expat, we can point neon
# there, otherwise, neon is on its own to find expat.
if test -f "$abs_builddir/apr-util/xml/expat/lib/expat.h" ; then
args="$args --with-expat='$abs_builddir/apr-util/xml/expat/lib/libexpat.la'"
fi
SVN_SUBDIR_CONFIG(neon, $args)
With neon 0.24.4, the same --with-expat option was passed in, but it
seemed to get ignored.
Any ideas on how we should fix this problem? We need a way of telling
not only if we have a bundled apr-util, but also that apr-util plans
to build its internal expat.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Build error with bundled apr-util and neon
Posted by Greg Hudson <gh...@MIT.EDU>.
"Nevermind." I think I had some cruft from a previous system rev in my
apr-util directory. "make clean" didn't take care of it (for
understandable reasons), but more drastic measures did. Sorry for the
false alarm.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org