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 <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 Sat Oct 7 19:20:12 2006