Ping...
Could a committer take a look at this patch? If nothing happens with in
the next few days, I'll file an issue.
-Hyrum
Kamesh Jayachandran wrote:
> 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.
> ]]]
Received on Mon Oct 2 22:09:36 2006