Thanks for your consideration of this issue. Unfortunately I have to
apologize, this is not an issue with r878293.
The issue arises when you are building subversion against apr/apu that has
already
been installed in a special location, was built with the internal expat,
and there is another incompatible apr/apu in the system location that
contains libexpat. Then many libraries will load the undesired (system)
apr/apu which leads to the test
failure.
The problem starts when the subversion make tries to configure serf.
It uses the results of "apu-1-config --link-libtool --libs" as a portion of
SERF_LIBS. Because
the apu is already installed this can include something like
"/specialpath/lib/libaprutil-1.la -lexpat".
When libtool links libserf the -lexpat option can turn into a dependency_lib
entry corresponding to the
system libexpat.la. This dependency then is inherited by libsvn_ra_serf,
and then by
libsvn_ra. In resolving these dependencies when linking downstream libs the
RPATH of the downstream libs
may contain a reference to the system location of libexpat (which contains
the downlevel system apr/apu).
As a result of the order of the generated RPATH entries libsvn_ra_serf
correctly loads the special apr/apu,
but libsvan_ra does not. Further downstream libraries also incorrectly load
the system apr/apu and
cause the test failure.
This can be avoided if serf is built outside of the subversion make by
configuring serf with
LDFLAGS=-L/specialpath/lib. Then the dependency_lib entry of libserf for
expat will refer to the
specially built libexpat.la instead of the system one. It can also be
avoided by building against the
special apr/apu build directories instead of the installed version. In this
case apu-1-config will
return something like
"/apr-util-buildpath/libaprtuil-1.la/apr-util-buildpath/xml/expat/
libexpat.la" for use
in SERF_LIBS, and the dependancy_lib entry in libserf-0.la will not refer to
the system libexpat.la,
which can prevent the path of the system libexpat from being added to RPATH
of the downstream libs.
My test system based on a RHEL 5 derivative.
It would be nice if it was easier to build subversion on this system,
but I am not sure this is a subversion problem, it seems more like an issue
with apr-util and serf.
But it certainly made it hard for me to build subversion!
On Mon, Aug 1, 2011 at 6:06 PM, Daniel Shahaf <d...@daniel.shahaf.name>wrote:
> I can't keep track of the chain of reversions there. Can you post this
> to dev@ please with a description of the regression --- i.e., how
> specifically the results you get from invocation X in 1.6.x differ from
> the results of X in 1.7.0-beta2, and where do you think
> configure.ac/Makefile.in are wrong (it sounds like you have that
> pinpointed).
>
> Thanks.
>
> tsteven four wrote on Mon, Aug 01, 2011 at 08:21:52 -0600:
> > 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/
> > >
>
