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

Re: auth-test fails (E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers)

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Sun, 13 Nov 2011 19:04:01 +0200

> On Sun, Nov 13, 2011 at 06:14:57PM +0200, Daniel Shahaf wrote:
> > Philip Martin wrote on Thu, Nov 03, 2011 at 10:55:49 +0000:
> > > Yes. The kwallet and gnome keyring providers are loaded dynamically and
> > > the loader will not look for providers in the right place.
> >
> > Why won't the loader look for them in the right place?

Jonathan Nieder wrote on Sun, Nov 13, 2011 at 10:32:44 -0600:
> For the case at hand: libtool never gets told that the auth-test wants
> to load auth providers because they are loaded using dlopen(), not
> ordinary library linkage. So libtool can avoid blame for this
> particular problem.

Stefan Sperling wrote on Sun, Nov 13, 2011 at 17:39:34 +0100:
> dlopen() accepts either an absolute pathname or the basename
> of a shared library. In the latter case, the library is searched
> in the standard library search path, and in dirs in LD_LIBRARY_PATH.
>

Thanks for the explanations.

> If we specified an absolute path we'd have to compile the abspath
> of the working copy containing the shared libs into the binaries
> to run tests. And re-compile with a different abspath during 'make install'.
> It would also prevent moving an existing SVN installation to a different
> prefix without recompilation. This could cause problems for packagers.

I'm not convinced that specifying an abspath is the end of the world; we
already do that for the "normal" shared libraries. (They get relinked
during 'make install', and if I rename the dir they were installed to
I get an error.)

% mv prefix suffix
% suffix/svn-1.7.0/bin/svn
suffix/svn-1.7.0/bin/svn: error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file: No such file or directory

On the other hand, I'm more concerned about how an installed libsvn_subr
loads its libsvn_auth_* libraries than about how auth-test does that.
I suppose the problem here would be that if one, for whatever reason,
has two copies of libsvn_auth_kwallet in $LD_LIBRARY_PATH:$LD_DEFAULT_SEARCH_PATH,
then svn will load the wrong one.

Which can probably lead to nastiness in one circumstances or another...

Thanks,

Daniel
(the question is which, and how likely it is)
Received on 2011-11-13 18:04:48 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.