I have the annoying SQLite header and source version mismatch
problem when trying to run SQLite3 on Ubuntu 13.04. I've done in various orders (and all multiple times):
apt-get remove sqlite3 libsqlite3-dev
, and reinstallationldconfig
- Compiled sqlite from source using the
autoconf
tar.gz - Tried everything I've found on Google...
Yet I can't figure out what's wrong. I've wasted 3 hours of my life on this!
And in fact, why does the following happen:
$ sqlite3
SQLite header and source version mismatch
2010-03-09 19:31:43 4ae453ea7be69018d8c16eb8dabe05617397dc4d
2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668
$ apt-get remove sqlite3
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'sqlite3' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
If sqlite3
isn't installed, how can it think there's a mismatch?!
Update
Right, thanks to Aaron, I've now got as far as
$ locate libsqlite3.so
/usr/local/lib/libsqlite3.so
/usr/local/lib/libsqlite3.so.0
/usr/local/lib/libsqlite3.so.0.8.6
I've moved them to a temp dir, and now get
$ sqlite3
The program 'sqlite3' is currently not installed. You can install it by typing:
sudo apt-get install sqlite3
I did
$ apt-get install sqlite3
$ apt-get install libsqlite3-dev
And STILL get the same mismatch error
And I've removed the spurious sqlite3.h
and sqlite3ext.h
files that were still around, repeated everything, and still get the issues...
Answer
More background: I was trying to install SQLite3 because when I ran any SVN command, I got an error:
E200029: Couldn't perform atomic initialization
E200030: SQLite compiled for 3.7.15.2, but running with 3.6.23
I assumed that fixing my install of SQLite would fix that. However, I think the main issue is that Ubuntu 13.04 requires SQLite 3.6.23, and that is the reason why running
apt-get purge libsqlite3-0
deletes most of Ubuntu (see this related answer for further details).
After lots of headbanging, shouting, and crying, I decided to try to install SVN from source (as opposed to SQLite, which is what I said I'd done in my question). This was actually relatively straightforward, albeit a little time-consuming.
Basically:
wget http://mirror.ox.ac.uk/sites/rsync.apache.org/subversion/subversion-1.8.1.tar.bz2
tar xjvf subversion-1.8.1.tar.bz2
I then found out I needed the APR and APR-utils libraries, so:
wget http://mirror.ox.ac.uk/sites/rsync.apache.org/apr/apr-1.4.8.tar.bz2
wget http://mirror.ox.ac.uk/sites/rsync.apache.org/apr/apr-util-1.5.2.tar.bz2
tar xjvf apr-1.4.8.tar.bz2
cd apr-1.4.8
./configure
make
sudo make install
cd ..
tar xjvf apr-util-1.5.2.tar.bz2
cd apr-util-1.5.2
./configure --with-apr=/usr/local/apr
make
sudo make install
...and the serf library (I didn't compile with this the 1st time, but this provides http support - without it SVN can only handle file
and svn
protocols)..:
wget https://serf.googlecode.com/files/serf-1.3.0.tar.bz2
tar xjvf serf-1.3.0.tar.bz2
scons APR=/usr/local/apr APU=/usr/local/apr
sudo scons install
scons -c
These are the same commands as in the serf README (if scons isn't installed it's available via apt-get
).
SVN also wants the SQLite amalgamation .c file, so download the amalagation and untar it for now - I created a ~/sqlite-amalgamation
folder and left everything here. You should then be ready to compile svn. Serf should have installed to a standard place, so doesn't need a location specified
sudo ./configure --with-sqlite=/home/chris/sqlite-amalgamation/sqlite3.c --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr --with-serf
make
sudo make install
and hopefully that's it. I had SVN error of
The working copy needs to be upgraded
but when I tried svn upgrade
I got a SVN database error... the only way round it was to checkout a new version into a new location. But, SVN now works!
It doesn't fix the underlying SQLite3 issue, and I still get the same header / source version mismatch error when doing $ sqlite3
, but since I don't need to use standalone SQLite at the moment, that problem can wait until another day (or, is it infact something that should be registered as a bug with Ubuntu?)
No comments:
Post a Comment