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 --with-sqlite=/tmp/sqlite-3.7.3/sqlite3.c

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!

MJB

On 11/23/2010 9:18 PM, Hyrum K. Wright wrote:
On Tue, Nov 23, 2010 at 6:16 PM, Michael J. Bauer
<mjba...@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

Reply via email to