Philip Martin wrote on Mon, Nov 14, 2011 at 08:59:46 +0000: > Daniel Shahaf <danie...@elego.de> writes: > > > Philip Martin wrote on Thu, Nov 03, 2011 at 10:55:49 +0000: > >> Jonathan Nieder <jrnie...@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.
