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.
