Subclipse error “svn: SQLite compiled for 3.8.6, b

Question

I am trying out the Mac OS X Yosemite beta [edit: same issue in full release], which seems to have broken my Eclipse/Subversion. When I attempt to perform any svn action, I get:

svn: Couldn't perform atomic initialization 
SQLite error 
svn: SQLite compiled for 3.8.6, but running with 3.8.5

I have installed subversion-javahlbindings +nobdb+universal using macports, which includes the most recent SQLite3 (3.8.6), so I have no idea where the 3.8.5 is coming from on my system.

Svn works fine on the commandline, but not Eclipse. I have looked at this similar problem and googled the relevant E200029 error code without success.

Since it works on the command line, I'm thinking there's something in my Eclipse setup which is somehow pointing to the wrong/old svn but I can't find anywhere I can change any settings that would apply.

Any advice? (other than the obvious switching my OS back to Mavericks)

Edit: I've got svnkit working to get the Eclipse svn functionality but still would like to figure out what's going on with the subversion-javahl for future reference.

Answer 1

This problem is caused by the fact that Yosemite appears to include a version of sqlite that is earlier than the one delivered by MacPorts. I have found a work-around to this problem by downgrading the version that MacPorts installs. MacPorts does not have 3.8.5 version of the port, so the following steps will manually do this. Also, the next time you do a port selfupdate you will wipe out these changes, so you may have to repeat these steps.

Type sudo port edit sqlite3

Edit the version and checksums lines to the following:

version             3.8.5
checksums           rmd160  b8da5ec594ac808da85469349c7506bd343946bf \
                sha256 98c33abe4106e508e73fda648b2657ac9e969fe24695f543dcde68cc71f3091b

Type sudo port install sqlite3

Type sudo port upgrade --force subversion-javahlbindings +no_bdb+universal

This will cause subversion to recompile against the 3.8.5 version of sqlite3.

Answer 2

I am on latest public Yosemite + MacPorts everything updated, Eclipse Luna 4.4 (STS 3.6.1), subclipse 1.10.5.

$ /usr/bin/sqlite3 --version
3.8.5 2014-08-15 22:37:57 c8ade949d4a2eb3bba4702a4a0e17b405e9b6ace

$ /opt/local/bin/sqlite3 --version
3.8.6 2014-08-15 11:46:33 9491ba7d738528f168657adb43a198238abde19e

I have a feeling macports' javahlbindings had some references to the 3.8.5 version. Didn't spend too much time to check.

My workaround is to use SVNKit (Pure Java) SVNKit v1.8.5.10237.
Eclipse->Preference->Team->SVN->SVN Interface->change from javahl to SVNKit
SVNKit is one of the Subclipse's feature. (SVNKit Client Adapter (Not Required))

Answer 3

I encounter the same problem, saying:

svn: E200029: Couldn't perform atomic initialization
svn: E200030: SQLite compiled for 3.8.9, but running with 3.8.8.3

and my svn version is downgrade from 1.8 to 1.7.14 by following this post: Install a Specific Version of a Tool on OS X With Homebrew。

But after downgrade svn, I got this sqlite error. I fixed the problem by this:

$ brew update
...omit a lot of output...
$ brew upgrade sqlite
==> Upgrading 1 outdated package, with result:
sqlite 3.8.10.2
==> Upgrading sqlite
==> Downloading https://homebrew.bintray.com/bottles/sqlite-3.8.10.2.yosemite.bottle.tar.gz
######################################################################## 100.0%
==> Pouring sqlite-3.8.10.2.yosemite.bottle.tar.gz
==> Caveats
This formula is keg-only, which means it was not symlinked into /usr/local.

Mac OS X already provides this software and installing another version in
parallel can cause all kinds of trouble.

OS X provides an older sqlite3.

Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:

    LDFLAGS:  -L/usr/local/opt/sqlite/lib
    CPPFLAGS: -I/usr/local/opt/sqlite/include

==> Summary
                                                                    

                                                        
            

查看更多

0人赞 添加讨论(0) 举报

Answer 4

I've been relying on Macports for the java HL for Eclipse Luna, and after I updated to Yosemite I, too, ran into the same problem. I use subversive instead of subclipse, but the error was the same. I decided to give Homebrew a try and to my surprise the SQLite error went away.

$ brew install --java subversion
$ brew options subversion # shows your options
$ brew install --universal --java subversion # Got Warning: subversion-1.8.10_1 already installed 
$ sudo mkdir /Library/Java/Extensions
$ cd /Library/Java/Extensions
$ sudo ln -sf /usr/local/lib/libsvnjavahl-1.dylib
$ sudo ln -sf /usr/local/lib/libsvnjavahl-1.jnilib
$ nano ~/.profile # add export PATH=/usr/local/bin:$PATH

Answer 5

I have solved this problem.

replace version to 3.8.5.0, it's ok.

1, # brew uninstall sqlite

2, # brew uninstall subversion

3, # brew edit sqlite

modify following content:

  3 class Sqlite < Formula
  4   homepage "http://sqlite.org/"
  5   url "https://www.sqlite.org/2014/sqlite-autoconf-3080500.tar.gz"
  6   version "3.8.5.0"
  7   sha1 "7f667e10ccebc26ab2086b8a30cb0a600ca0acae"

 34   resource "docs" do
 35     url "https://www.sqlite.org/2014/sqlite-doc-3080500.zip"
 36     version "3.8.5.0"
 37     sha1 "c5655a4004095c50dc8403661e0ed02fd4191d57"
 38   end

like vim , :wq to save changes and quit.

4, # brew install --universal --java subversion

5, # rm -f /Library/Java/Extensions/libsvnjavahl-1.dylib delete symbolic link file;

6, # sudo mkdir -p /Library/Java/Extensions # sudo ln -s /usr/local/lib/libsvnjavahl-1.dylib /Library/Java/Extensions/libsvnjavahl-1.dylib

7, reboot Eclipse, it's OK.

Answer 6

I see the same thing here. Fresh macports, rebuilt sqlite3 and subversion*. Everything works in command line, but eclipse / subclipse fails with

SQLite compiled for 3.8.7, but running with 3.8.5

Looks fishy that svn links with both versions. I tried adding --with-sqlite3=${prefix} to the Portfile for subversion and subversion-javahlbindings, but that did not help.

$ svn --version  --verbose|grep sql
- /opt/local/lib/libsqlite3.0.dylib   (64-bitars Intel)
- /usr/lib/libsqlite3.dylib   (64-bitars Intel)

Any ideas how to resolve this, apart from using the somewhat more insecure native binding?