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

Re: svnsync_test.py fails: wrong version of SQLite library

From: Michael J. Bauer <mjbauer_at_eecs.tufts.edu>
Date: Wed, 24 Nov 2010 14:14:04 -0500

The documentation on how to use the amalgamation should be clearer.
After many false starts, I got it to successfully configure with:

./configure --prefix=/usr/sup/subversion-1.6.13

I'm mildly surprised that it can't find sqlite3.c if you feed it a
directory with the amalgamation file in it
(--with-sqlite=/tmp/sqlite-3.7.3). I'm somewhat less surprised in it
being unable to unpack a tarball to find the appropriate file. Note
that without having found the right bit of SQLite documentation,
SQLite's distribution file is what I would assume is the 'amalgamation',
as it has that word in its name.

That said, it built fine, and passed all tests.

Thanks for the pointer!


On 11/23/2010 9:18 PM, Hyrum K. Wright wrote:
> On Tue, Nov 23, 2010 at 6:16 PM, Michael J. Bauer
> <mjbauer_at_eecs.tufts.edu> wrote:
>> I am attempting to build SVN on a RHEL 5.4 system. There are two versions
>> of SQLite on the system:
>> * The stock system SQLite, version 3.3.6, with library in /usr/lib
>> * A new version of SQLite, version 3.7.3, with library in /usr/sup/lib
>> I configured SVN with the following options:
>> ./configure --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/
>> (The prefix is because I do not want to clobber the system version of SVN,
>> just make a newer one available.) The build worked without issue; however,
>> 'make check' fails. When I look at the log, I see the following error
>> repeatedly:
>> svnsync: SQLite compiled for 3.7.3, but running with 3.3.6
>> It looks like svnsync is picking up the wrong version of SQLite, despite
>> being compiled with the correct version. This appears to happen only on
>> svnsync synchronize, but I've not exhaustively read through the logs. I've
>> re-run the tests with LD_LIBRARY_PATH, LD_RUN_PATH, and LIBRARY_PATH set
>> identically to /usr/sup/lib:/usr/local/lib, to no change in behavior.
>> To make sure I wasn't missing something, I rebuilt SVN, configuring it with
>> explicit environment variables:
>> ./configure LDFLAGS=-L/usr/sup/lib CPPFLAGS=-I/usr/sup/include
>> --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/
>> It fails 'make check' in exactly the same way.
>> When I look at subversion-1.6.13/subversion/svnsync/svnsync, the shell
>> script appears to be clobbering the run-time environment variables. I'm not
>> sure this is pertinent, given that it fails with or without the run-time
>> variables set, and with or without LDFLAGS and CPPFLAGS set.
>> How do I get SVN to pick up the correct version of the library on 'make
>> check' when --with-sqlite (with or without compile-time and run-time
>> environment variables set) doesn't do the right thing?
> Have you tried building Subversion with the sqlite amalgamation? You
> can point --with-sqlite at an amalgamation file (as downloaded from
> sqlite.org), and Subversion will statically include that, removing
> library conflicts.
> -Hyrum
Received on 2010-11-24 20:14:55 CET

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.