On Jun 6, 2017, at 13:56, Daniel Shahaf wrote:
> The runtime linker finds libsvn_gnome_keyring.so in /usr/lib, rather
> than the one in the build tree.
OK, that makes sense (I think).
> Your options include:
>
> - Link statically. (--enable-all-static to configure)
When I first tried this I was getting a link error because it couldn’t find
/usr/lib/libapr-1.a. But somehow now the problem went away, and even after
doing a “svn cleanup —-delete-ignored” and running autopen.sh and ./configure
again without the —-enable-all-static option) I am getting a statically
linked binary. Weird, but at the moment irrelevant to my next problem.
> - Set LD_LIBRARY_PATH as in my 'manual' example. (If running from the
> build tree, I think you'll need to point it to subversion/libsvn_*/.libs/;
> if running from an installed tree, point it to ${prefix}/lib.)
There was no keyring library in the output of “ldd” when I the binary was
linked dynamically.
> - Run the executable as 'libtool --mode=execute ./svn-mergeinfo-normalizer'.
> (There'll be a 'libtool' script in the root of the build tree.)
That didn’t work for me.
> - Pass --prefix to configure, then run 'make install-tools', and run the
> binary from ${prefix}/bin/svn-tools/ rather than from the build tree.
I did this, and I can run the svn-mergeinfo-normalizer tool now without
setting PATH or LD_LIBRARY_PATH to my prefix directory. However, when I
run the tool on an existing sandbox, I get the following error:
Scanning working copy /scratch/sandbox/XXX//trunk ...
svn: E170000: Unrecognized URL scheme for 'https://svn.xxx.com/hepd/XXX/trunk'
I thought perhaps I needed to check out a fresh sandbox with the newly
build 1.10 svn binaries, but I get the same error. I guess I need to
pass some additional options to ./configure?
> - (included for completeness) Temporarily move /usr/lib/libsvn*.so out
> of the way while testing.
I didn’t want to try this.
