On 5/19/14, 3:11 AM, Julian Foad wrote:
>> There was extra cruft in that patch from a previous discussion. Only
>> the Makefile.in bit is relevant. Trimmed patch attached.
>
> Talking of cruft... Do you know why that "if" condition exists at all? Why do we set the library path only if the library path variable is named DYLD_LIBRARY_PATH or LD_LIBRARY_PATH -- are there some names for which we should not do this?
>
>> case "@SVN_APR_SHLIB_PATH_VAR@" in
>> DYLD_LIBRARY_PATH|LD_LIBRARY_PATH)
>> # append the required library paths to the variable
>
> (I tried to run "svn blame" to look for clues to what the original author meant, but the repository server is currently not responding.)
The only reason we have to do that DYLD_LIBRARY_PATH dance is because we can't
effectively use rpath on OS X (due to way rpath is implemented in the Mach
executable format on OS X, which is outside the scope of this email thread).
On platform's like Linux in this case, the rpath is functional for our
purposes. Adding a LD_LIBRARY_PATH hides the broken linkage, so it's
undesirable (except as a last resort when we can't avoid it any other way).
Julian's fix is good enough in my opinion. It solves the problem that is most
likely to crop up, specifically the system installed libraries conflicting with
the test.
What it doesn't solve is a case where some other version of Subversion
libraries in installed in a non-standard lib directory that also happens to be
the directory you're using to get Serf or BDB. But I don't see a way to
actually fix this case and so I'd much rather see us leave this problem in
place, because there is a real problem there.
It'd actually be nice if the busted linkage caused our other tests to fail but
libtool hides it from us. We could get rid of libtool, but libtool provides a
bunch of functionality that isn't easily replaced.
Received on 2014-05-19 16:34:18 CEST