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

Re: svn commit: r19901 - trunk

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2006-06-03 15:22:48 CEST

"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

> 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

> - 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

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