[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

SOLVED: Unsupported RA plugin ABI version (2) for ra_dav.

From: Alexander L. Belikoff <abel_at_vallinor4.com>
Date: 2004-07-21 13:48:22 CEST

OK, figured this one out. Apparently, if I try to build WITH dav support but
WITHOUT a copy of neon, the build process decides to use the following
strategy:

1. Print a one-line inconspicious warning about neon missing, which would
result in DAV support being excluded (never mind that I asked for it to be
in).
2. CONTINUE to build without DAV support.
3. Leave me with seemingly working build.

Please tell me this was intended to be that way in order to serve as an
initiation rite for anyone joining in on SVN development. :-)))

Seriously, I'll see if I can hack the autoconf stuff to fail if the above
condition is met. However, it would still make sense to make SVN work without
ra_dav for local access.

On Wednesday 21 July 2004 01:10, Alexander L. Belikoff wrote:
> I'm trying to build subversion in a private directory to play w/ some ideas
> and it builds fine. However it doesn't allow me to import any code, giving
> me the error:
>
> $ svn import -m "test import" apache file:///home/abel/svnwork/repo
> svn: Unsupported RA plugin ABI version (2) for ra_dav.
>
> According to what I see, libsvn_ra_dav.so doesn't even get built. Strace
> shows that the binary tries to find libsvn_ra_dav-1.so.0, doesn't find it
> in the private installation tree and then falls back to ldconfig PATH which
> helpfully serves it /usr/lib/libsvn_ra_dav-1.so.0 from Subversion 1.0.4
> provided by the distribution. I assume that this instance is incompatible
> with whatever is expected by the up-to-date tree.
>
> Hence the questions:
>
> 1. How do I get the thing to build properly?
> 2. If I have to enable DAV explicitly, then why? One would think that
> missing plugin for access type that is not utilized should not be an issue.
> 3. If I am right about my conclusions above, then why is do those libraries
> retain the very same name and version? Shared library versioning was
> created specifically to alleviate such issues and upgrading the plugin
> version for each ABI change would be a natural step.
>
> In any case, some help w/ building the thing would be greatly appreciated.
>
> Thanks in advance,
>
>
> P.S. The system is Fedora Core 2

-- 
Alexander L. Belikoff                      GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9
Bloomberg L.P.                                       424B A86E CD0D 8424 2701
abel *at* vallinor4 *dot* com             (http://pgp5.ai.mit.edu for the key)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 21 13:48:34 2004

This is an archived mail posted to the Subversion Dev mailing list.