On Fri, Jul 29, 2011 at 10:48:47AM -0600, tsteven four wrote:
> Thanks, I will look at your workarounds.
>
> On my system the troubles seem to be because /usr/lib64 gets put into RPATH
> in all the .so libs in subversion/bindings/swig/python/* (including the
> subdirectories). It is put in RPATH before the path element for the apr,
> apr-util that I have built. If I use patchelf to reset the RPATH removing
> /usr/lib64 entirely in subversion/bindings/swig/python/.libs/_core.so then
> all the checks pass. Note that I removed /usr/lib64, I didn't move it to
> the end of the RPATH. So now I ask why does /usr/lib64 get put into the
> RPATH at all? It seems to cause a lot of problems, and not only with the
> bindings.
Is libpython.*.so in /usr/lib64, by chance?
I suppose libtool puts the RPATH in there to make sure the .so files
in the bindings can find libpython.*.so.
This is not necessary since python is already running when these
.so files get loaded, and python has loaded libpython.*.so.
So without the RPATH you can run the tests, since no incompatible
apr libraries are loaded from /usr/lib64.
But how can libtool, which is unaware of this and just treats the
bindings .so files as general shared libraries, know about that?
In my build I get this (quote from swig/python/_wc.la:)
-Wl,-rpath=/home/stsp/svn/prefix/python/lib
-L/home/stsp/svn/prefix/bz2/lib -L/home/stsp/svn/prefix/python/lib
-lpython2.7
It boils down two choices options:
1) use only system dependencies
2) use only dependencies you have compiled yourself and installed into a
custom prefix, and which do not pull in incompatible system deps.
If any dependency pulls in incompatible deps, compile those deps
yourself, too, until everything is smooth
The middle ground between those options is littered with countless
problems and spurious test failures.
Received on 2011-07-29 19:12:00 CEST