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.
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan_at_debian.org>
Received on 2014-05-14 04:05:36 CEST