[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.7.0-beta1 up for testing / signing

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 15 Jul 2011 09:28:30 +0100

Peter Samuelson <peter_at_p12n.org> writes:

> [Philip Martin]
>> I'm seeing the same thing, reverting r1037358 appears to be enough to
>> make the tests run.
> Did you run 'perl Makefile.PL' in subversion/bindings/swig/perl/native
> _before_, or _after_, the main build? It matters.
> If you run it _before_ the main build, the pre-r1037358 will produce a
> bunch of empty -L flags. I fixed that in r1037358, so they get the
> directories they apparently were supposed to have attached.
> If you run it _after_ the main build, r1037358 makes almost no
> difference. The only difference I see is a ${LD_LIBRARY_PATH} has been
> changed to $(LD_LIBRARY_PATH). Should be equivalent.
> Thus I conclude that you probably ran it _before_ the main build, and
> that somehow all those -L flags that the previous code did not pick up
> but the current code does, are breaking your testsuite run. Could you
> post the generated 'obj-1.7/subversion/bindings/perl/native/Makefile'
> with and without r1037358 in the source? (You can regenerate the
> Makefile.PL by running ./config.status in obj-1.7/.)

The perl bindings are really confusing. Start from scratch:

make swig-pl
make check-swig-pl # PASS
make clean-swig-pl
make swig-pl
make check-swig-pl # FAIL

It was that FAIL after the rebuild that was confusing me. I get the
same thing in 1.6 so this is not a regression.

So r1037358 is not a problem, it's simply that when I reverted it I also
manually removed enough of the perl build that my environment got back
to the state in which the tests would PASS the first time.

>> It's not clear that that is enough, the installed
>> shared objects still refer to the build directory:
>> $ objdump -x /usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so | grep RPATH
>> RPATH /home/pm/sw/subversion/obj-1.7/subversion/libsvn_client/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_delta/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_fs/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_ra/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_repos/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_wc/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_diff/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_subr/.libs:/home/pm/sw/subversion/obj-1.7/subversion/bindings/swig/perl/libsvn_swig_perl/.libs
> I think that's been the case for a long time. I actually have a patch
> in the Debian build specifically to work around this, dating from ages
> and ages ago.

Should we put this patch into Subversion?

uberSVN: Apache Subversion Made Easy
Received on 2011-07-15 10:29:17 CEST

This is an archived mail posted to the Subversion Dev mailing list.