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

Re: Issues with bindings tests

From: James McCoy <jamessan_at_debian.org>
Date: Tue, 13 May 2014 22:00:55 -0400

On Tue, May 13, 2014 at 10:11:13AM +0100, Julian Foad wrote:
> More details. The bug shows up when all of these conditions are met:
>
>   * there is a development package of Subversion libraries, that we don't
>     want to use, installed somewhere (such as /usr);
>
>   * the 'serf' package that we are building against is installed under that
>     same prefix (such as /usr);
>
>   * 'pkgconfig' is not being used to find the 'serf' package.
>
> The cause is that the detection of 'serf' inserts '/usr/lib' into the
> library search path(s) and then the installed Subversion development
> libraries are picked up instead of the Subversion libraries that we
> are building.

Thanks for the diagnosis. I had encountered this when testing a
Debian's packaging recently.

> I witnessed two failure modes with an unwanted Subversion 1.8.8
> development package and the wanted 'serf' package both installed under
> /usr. Subversion 1.9-dev failed to link at build time. A Subversion
> 1.8.9 build completed, and all the tests passed except the JavaHL
> bindings. The JavaHL test code linked to a 1.8.8 library, and at run
> time that dynamically loaded a 1.8.9 library, and a version check
> reported a mismatch. (Another time, the python-ctypes bindings failed
> in the same way.)
>
> As far as I understand it (which isn't very far) there is no general
> solution to having some wanted and some unwanted libraries installed
> in the same place, because the dynamic library search mechanism only
> has the granularity of a path.

Isn't this something that LD_LIBRARY_PATH can help with? There's
already code in Makefile.in to set DYLD_LIBRARY_PATH in order to pick up
the test libraries in preference to the system-wide libraries. This
should probably be expanded to also happen when
@SVN_APR_SHLIB_PATH_VARS@ is LD_LIBRARY_PATH.

I had tried the below patch but ran into some other issues that I didn't
have the time/experience to properly diagnose.

Cheers,

-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan_at_debian.org>

Received on 2014-05-14 04:05:36 CEST

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