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

Re: back-end fsfs DB corruption? - attempt to merge uncovering it

From: Paul Hammant <paul_at_hammant.org>
Date: Tue, 15 Sep 2009 15:00:36 -0500

> OK, one last question if I may:
> Are you sure that the svn binary you've built is using the correct
> libsvn_* libraries? If it happens to load the old ones, which can
> happen on Linux where shared lib dependencies are resolved at runtime,
> depending on your configuration, then it could be calling into a wrong
> shared library which does not have the fix applied.

No, I'm not sure that's the case. I'm a Java guy mostly, and an
infrequent visitor to configure/make/gcc. Doing a "svn --version" was
yielding plausible version numbers [1.6.6 (dev), 1.6.5(38xxx) and
alike ]. How could I tell that transitive deps were right or wrong ?

We're Fedora core 10, and yum installed the non-svn deps like
libtool. It is true that Svn was already in the path at build time,
but nothing the flew past in configure or make looked to be pointing
to prior items.

We still have the 1.6.5+2patch, and the 1.6.x-r38000 checkouts and can
build again. How can we be 100% sure that we're not dragging in
inappropriate deps ?

- Paul


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-15 22:02:02 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.