You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2006/10/02 20:09:22 UTC
Re: [PATCH] Better fix for convoluted installations.(where 3rd party
libs collocated in old version of svn)
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 <ka...@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.
> ]]]
Re: [PATCH] Better fix for convoluted installations.(where 3rd party
libs collocated in old version of svn)
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Hyrum K. Wright wrote:
> Ping...
>
> Could a committer take a look at this patch? If nothing happens with in
> the next few days, I'll file an issue.
Filed as issue 2625.
-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 <ka...@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.
>> ]]]
>