Re: Issues with bindings tests

Julian Foad  wrote:
> I ran into the following issues, testing the 1.7 and 1.8 releases recently. Some
> but not necessarily all of these are still a problem on trunk.
>
>   1. JavaHL bindings tests tried to load the libs from /usr, if I had a
> Subversion dev package installed there.

> 1. serf.m4 lacks the "SVN_REMOVE_STANDARD_LIB_DIRS" that is present in
> (most of) the other .m4 files. A proper fix is to change build/ac-macros/serf.m4
> like this (in two places):
>
> -      LDFLAGS="$LDFLAGS -L$serf_prefix/lib"
> +      LDFLAGS="$LDFLAGS `SVN_REMOVE_STANDARD_LIB_DIRS(-L$serf_prefix/lib)`"

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.

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. But we have a precedent that helps with the common cases: when making additions to LDFLAGS we strip out standard installation paths. In 'serf.m4' we omitted to do this.

The manifestation I observed was also different between the version of libtool' in the tarball and the version on my (Ubuntu 12.04 64-bit) system. On my 1.8.9 tarball test build, re-running 'autogen.sh' so as to switch to using the system-installed libtool changed the behaviour and avoided the problem.

> This fix still needs to be applied to trunk, as far as I can see, although
> trunk's better support for 'pkgconfig' meant that this code was
> bypassed on my system (and the pkgconfig code worked fine).

Confirmed, by temporarily disabling the check for pkgconfig.

By code inspection, I found one other place that needs the same fix: in 'berkeley-db.m4', for the case where you specify --with-berkeley-db="x:y:LIBDIR:z" and LIBDIR is a standard system location such as "/usr/lib".

Committed to trunk in r1594156 and proposed for backport to 1.8.x in r1594157. We might also want it in 1.7.x.

Please let me know if there's any problem with the analysis or the fix.

- Julian
Received on 2014-05-13 11:11:51 CEST