[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...


(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.