Philip Martin wrote on Mon, Nov 14, 2011 at 08:59:46 +0000:
> Daniel Shahaf <danielsh_at_elego.de> writes:
>
> > Philip Martin wrote on Thu, Nov 03, 2011 at 10:55:49 +0000:
> >> Jonathan Nieder <jrnieder_at_gmail.com> writes:
> >>
> >> > The failure is described in tests.log:
> >> >
> >> > START: auth-test
> >> > svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
> >> > FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
> >> > END: auth-test
> >> > ELAPSED: auth-test 0:00:00.179133
> >> >
> >> > Indeed, instrumenting the test, we learn that the actual number of
> >> > providers returned is 1.
> >> >
> >> > Known problem?
> >>
> >> 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?
> >
> > Is this the ancient Debian libtool issue, or something else?
> >
> > Asking because fixing the loader seems to be a more correct solution
> > than fixing EVERYONE who runs the auth-test binary to set LD_LIBRARY_PATH
> > first.
>
> What sort of fix to the loader? The installed code cannot load dynamic
> libraries from the build dir, that would be a security issue. So that
> means the test code cannot load from the build dir by default either,
> unless we do some sort of recompilation on install. The only way for
> the test code to load modules from the build dir is to use
> LD_LIBRARY_PATH or LD_PRELOAD.
Short of recompile-at-install, would it make sense to getenv() at
auth-test.c:main() and do a sanity check on $LD_LIBRARY_PATH and
$LD_PRELOAD? That way, at least, callers that forget to set those env
vars will not accidentally load the wrong shared libs.
Received on 2011-11-14 17:05:49 CET