Hi All,
I use libtool 1.5.6
I have /home/kamesh/work/install-1.3.1/bin/ is ahead of everything else
in PATH.
I have neon, apr, apr-util, subversion-1.3.1 installed under
/home/kamesh/work/install-1.3.1/
So when I build svn-1.5.0(trunk) I get neon from
/home/kamesh/work/install-1.3.1/lib, which has '1.3.1 svn' libs too.
With current build.conf having 'neon' added explicitly to end of 'libs'
list of each binary makes sure that built 'lt-svn' always has
$BUILDDIR/subversion/libname/.libs ahead of
'/home/kamesh/work/install-1.3.1/lib' and hence no issue.
When I removed 'neon' from the libs list of executables I could
reproduce the error('version mismatch in linking different versions of
the libs(1.3.1 and trunk(1.5.1)')
I suggest the following fix rather than specifying each external library
explicitly for each executable.
Move our library(which has direct dependency to third party libs) to end
of 'libs' line.
i.e
-libs = libsvn_client libsvn_wc libsvn_ra libsvn_delta libsvn_diff
libsvn_subr
- apriconv apr neon
+libs = libsvn_client libsvn_wc libsvn_delta libsvn_diff libsvn_subr
libsvn_ra
+ apr apriconv
This works.
I had a concern about "what would be the effect if libsvn_subr is ahead
of other libs"(libsvn_subr depends on xml, expat in this case is located
under /home/kamesh/work/install-1.3.1/lib)?
To my surprise I did not get any error.
I wanted to do one more research i.e place apr ahead of everything
else(I have apr at /home/kamesh/work/install-1.3.1/lib).
i.e
-libs = libsvn_client libsvn_wc libsvn_ra libsvn_delta libsvn_diff
libsvn_subr
- apriconv apr neon
+libs = apr libsvn_client libsvn_wc libsvn_delta libsvn_diff libsvn_subr
libsvn_ra
+ apr
Hoping that, it would place /home/kamesh/work/install-1.3.1/lib ahead of
everything else(our trunk builddir '.libs') and hence might reproduce
the error.
To my surprise again I did not get any error.
This observation is justified by(readelf -a /path/to/lt-svn),
RPATH inside the 'lt-svn'(In both of the above experiments) binary is
0x0000000f (RPATH) Library rpath:
[/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_client/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_wc/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_ra/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_diff/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_delta/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_subr/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_ra_local/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_repos/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_fs/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_fs_fs/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_ra_svn/.libs:/home/kamesh/work/svn/pure_trunk/vpath/subversion/libsvn_ra_dav/.libs:/home/kamesh/work/install-1.3.1/lib:/home/kamesh/pure_trunk/lib]
Answer to above surprise results:
The problem is if the external lib is used by only one shared lib then
the 'external lib location' is placed in the same position in RPATH as
the 'libs' line in the build.conf.
E.g 'neon' being consumed directly by 'libsvn_ra_dav' only.
This causes the confusion of loading few libs from '1.3.1' and few from
'trunk'.
In case of 'xml' and 'apr' both libs are consumed by many other shared
libs and hence the libtool intellignetly adds their location at the
end(Refer the above RPATH, /home/kamesh/work/install-1.3.1/lib is behind
the build dirs).
So the proper fix is to move any library having the third party
dependency and that third party dependency is solely needed by this
library alone to the end of 'libs' specification of an executable in
build.conf.
E.g 'libsvn_ra_dav' needs 'neon' and noother lib constituting 'svn' has
direct dependency with 'neon'.
We have similar issue with sqlite too in merge-tracking branch. Attached
patch works for similar issue with 'sqlite' in merge-tracking branch.
Moving the libsvn_ra to end of 'libs' line of 'svn' binary fixes that too.
The same problem should definitely be there for 'serf' and 'bdb' too,
though I did not try.
I am attaching the patch against the trunk.
Currently I would like to limit myself to do this change for 'exe'
programs and 'libsvnjavahl'(which seem to explicitly refer neon) alone,
if need arise might do it for applicable libs like libsvn_client too.
With regards
Kamesh Jayachandran
Index: build.conf
===================================================================
--- build.conf (revision 21604)
+++ build.conf (working copy)
@@ -112,32 +112,13 @@
# BUILD TARGETS
#
-# Explanation for the seemingly-spurious mention of 'neon' in the libs lines
-# for svn, svnsync, ra-local-test, svn-push and mucc:
-# This is a workaround for a libtool bug, which manifests on Linux and similar
-# ELF platforms, when linking to an installed Neon, and there are old
-# Subversion libraries in the same directory as the installed Neon. In such
-# cases, the run-before-installing version of the executables (.libs/lt-foo),
-# gets given an ELF RPATH which includes the install directory *before* all the
-# uninstalled libsvn_foo/.libs directories have been mentioned. This occurs
-# because when libtool is at the point of handling Neon, it adds an RPATH entry
-# pointing to its directory, but fails to correctly consider that it should
-# prioritize all the RPATH entries for *un*installed libraries before all those
-# for installed libraries, to avoid this bug. As a kludgy workaround, we add
-# a mention of 'neon' to the end of the libs lines for executables which
-# indirectly link to libsvn_ra_dav, which has the effect of 'pulling' the
-# harmful RPATH entry toward the end of RPATH, enabling the executables to run
-# correctly before installation, even when old versions of the Subversion
-# libraries are present.
-# This bug was last confirmed to be present in libtool 1.5.22.
-
# The subversion command-line client
[svn]
description = Subversion Client
type = exe
path = subversion/svn
-libs = libsvn_client libsvn_wc libsvn_ra libsvn_delta libsvn_diff libsvn_subr
- apriconv apr neon
+libs = libsvn_client libsvn_wc libsvn_delta libsvn_diff libsvn_subr libsvn_ra
+ apriconv apr
manpages = subversion/svn/svn.1
install = bin
@@ -182,7 +163,7 @@
description = Subversion repository replicator
type = exe
path = subversion/svnsync
-libs = libsvn_ra libsvn_delta libsvn_subr apr neon
+libs = libsvn_delta libsvn_subr libsvn_ra apr
install = bin
manpages = subversion/svnsync/svnsync.1
@@ -486,8 +467,8 @@
description = Subversion Java HighLevel binding
type = lib
path = subversion/bindings/java/javahl/native
-libs = libsvn_repos libsvn_client libsvn_wc libsvn_ra libsvn_delta libsvn_subr
- aprutil apriconv apr neon
+libs = libsvn_repos libsvn_client libsvn_wc libsvn_delta libsvn_subr libsvn_ra
+ aprutil apriconv apr
sources = *.cpp *.c
add-deps = $(javahl_javah_DEPS) $(javahl_java_DEPS)
install = javahl-lib
@@ -710,8 +691,8 @@
path = subversion/tests/libsvn_ra_local
sources = ra-local-test.c
install = test
-libs = libsvn_test libsvn_ra_local libsvn_ra libsvn_fs libsvn_delta libsvn_subr
- apriconv apr neon
+libs = libsvn_test libsvn_ra_local libsvn_fs libsvn_delta libsvn_subr libsvn_ra
+ apriconv apr
# ----------------------------------------------------------------------------
# These are not unit tests at all, they are small programs that exercise
@@ -891,14 +872,14 @@
path = contrib/client-side/svn-push
sources = svn-push.c
install = contrib
-libs = libsvn_ra libsvn_delta libsvn_subr apriconv apr neon
+libs = libsvn_delta libsvn_subr libsvn_ra apriconv apr
[mucc]
type = exe
path = contrib/client-side
sources = mucc.c
install = contrib
-libs = libsvn_client libsvn_ra libsvn_subr apriconv apr neon
+libs = libsvn_client libsvn_subr libsvn_ra apriconv apr
[diff]
type = exe
[[[
Patch by: Kamesh Jayachandran <kamesh@collab.net>
To fix the RPATH pollution if 'neon is located in the same directory as the
old svn libs', the right approach would be to move libsvn_ra to the end of
'libs' list of exe's getting built and remove 'neon' from explicitly mentioned.
* build.conf
(global): Removing the 'comment on reasoning for spurious mention of neon'.
(svn): Remove 'neon' from 'libs'.
Move 'libsvn_ra' to end.
(svnsync): Remove 'neon' from 'libs'.
Move 'libsvn_ra' to end.
(libsvnjavahl): Remove 'neon' from 'libs'.
Move 'libsvn_ra' to end.
(ra-local-test): Remove 'neon' from 'libs'.
Move 'libsvn_ra' to end.
(svn-push): Remove 'neon' from 'libs'.
Move 'libsvn_ra' to end.
(mucc): Remove 'neon' from 'libs'.
Move 'libsvn_ra' to end.
]]]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 26 12:44:54 2006