"Erik Huelsmann" <ehuels@gmail.com> writes:
> RPATH /www/erik/dev/svn-dev/trunk/subversion/tests/.libs
> /www/erik/dev/svn-dev/trunk/subversion/libsvn_ra_local/.libs
> /www/erik/dev/svn-dev/trunk/subversion/libsvn_ra/.libs
> /www/erik/dev/svn-dev/trunk/subversion/libsvn_repos/.libs
> /www/erik/dev/svn-dev/trunk/subversion/libsvn_fs/.libs
> /www/erik/dev/svn-dev/trunk/subversion/libsvn_ra_svn/.libs
> /www/erik/dev/svn-dev/trunk/subversion/libsvn_ra_dav/.libs
> /usr/local/lib
> /www/erik/dev/svn-dev/trunk/subversion/libsvn_fs_fs/.libs
> /www/erik/dev/svn-dev/trunk/subversion/libsvn_delta/.libs
> /www/erik/dev/svn-dev/trunk/subversion/libsvn_subr/.libs
> /usr/local/apr/lib
>
> Notice that the RPATH contains /usr/local/lib before the paths to
> libsvn_{subr,delta,fs_fs}. That's why it's loading the wrong binaries
> for those.
From its position it looks like it's something to do with the
ra_dav library, is there a /usr/local/lib in libsvn_ra_dav-1.la?
Does the RPATH for libsvn_ra_dav-1.so include /usr/local/lib?
You could also look at relink_command in the libtool generated
"executable" script for whichever executable you are examining. First
look at the start of the file where relink_command is defined and add
a -v parameter to the gcc call. To see it in action go down the file
to where relink_command is executed and add an "echo $relink_command"
and also remove the 2>&1 redirection from the line that executes
relink_command. If you now delete the .libs/lt-xxx executable and
rerun the xxx script you will see the gcc and collect2 commands used
to link the executable. The collect2 command will include --rpath
parameters.
> In the 'after' version, the /usr/local/lib has moved to the end of the
> path list.
>
> More details on my system:
>
> - libtool 1.5.20
> - ld.so.conf does not include any path in /usr/local
> - libneon is in /usr/local/lib (does not contain RPATH)
Right, so it probably is the ra_dav library that is adding
/usr/local/lib.
> - libexpat is in /usr/lib (does not contain RPATH)
> - apr(util) is in /usr/local/apr/lib (does not contain RPATH)
> but, also in /usr/lib (also not containing RPATH)
>
> The libraries which do not contain RPATH fields have been built with
> the debian libtool...
>
> Any idea if my setup is too strange to work? Problematically set up?
It certainly can be tricky to pick up some of /usr/local/lib without
getting all of it. I guess installing neon in /usr/local/neon would
be one way to work around the problem.
I think this indicates why your patch is wrong -- it is specifically
tuned to your particular setup since it makes ra_dav the last
Subversion library but that's not a general solution. It's probably
possible to trigger a similar problem with fs_base/BDB rather than
ra_dav/neon and so "fixing" it by tweaking the library order seems
wrong to me.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 3 15:23:17 2006