I believe I have chased this down to r878293, a change to apr.m4 and aprutil.m4. SVN_APR_LIBS and SVN_APRUTIL_LIBS used to be set based on --link-libtool, now they are set on --link-ld. But when building the swig-py target the libraries are linked with libtool and thus according to the apr-1-config/apu-1-config help the --link-libtool option is correct. When I look at my 1.6.17 build the subversion/bindings/swig/python/.libs correctly include the local apr and aprutil, but in 1.7.0-beta2 they are picking up the system versions.
On Fri, Jul 29, 2011 at 12:21 PM, Daniel Shahaf <d...@daniel.shahaf.name>wrote: > Stefan Sperling wrote on Fri, Jul 29, 2011 at 18:32:40 +0200: > > On Fri, Jul 29, 2011 at 09:12:57AM -0600, tsteven four wrote: > > > ldd and readelf shown above. Is there some method to get python use > the > > > RPATH in libsvn_ra_serf as ldd does so the correct libapr is found, or > is > > > the python check overriding RPATH with > > > some method like LD_LIBRARY_PATH? > > > > Yes, you need to set LD_LIBRARY_PATH. > > You also need to make sure that none of the libraries that get loaded > > indirectly load the incompatible system libraries... it can get quite > hairy. > > I'm not sure I recommend your build --- it rebuilds its own python and > bzip2. > > Personally I'm trying to see if just installing the system svn to an > out-of-${*PATH} location works. (ie, I used this technique on one box > and now I'm trying to see if I can survive that way) > > > See this for various workarounds that I use in my build: > > https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/unix-build/ >