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