Re: 1.7 check-swig-py failure

[tsteven four <ts...@gmail.com>]

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/
>

Re: 1.7 check-swig-py failure

[tsteven four <ts...@gmail.com>]

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.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/
> > >
>

Re: 1.7 check-swig-py failure

[Daniel Shahaf <d....@daniel.shahaf.name>]

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/
> >