subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tsteven four <tstev...@gmail.com>
Subject Re: 1.7 check-swig-py failure
Date Mon, 01 Aug 2011 14:21:52 GMT
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.s@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/
>

Mime
View raw message