I had some flaky issue with Subclipse where it could not communicate with one particular repository with https. Everything worked fine with straight svn at the command line and through the browser, but no dice in Eclipse. After many agonizing hours (as very little of this was clear from logs, error messages, etc… I had to rely on google search after google search), I finally determined that I would just have to use the JavaHL connector, but for some reason, JavaHL was not available.
Failed to load JavaHL Library.
These are the errors that were encountered:
no libsvnjavahl-1 in java.library.path
no svnjavahl-1 in java.library.path
/opt/local/lib/libsvnjavahl-126.96.36.199.dylib: no suitable image found. Did find: /opt/local/lib/libsvnjavahl-188.8.131.52.dylib: mach-o, but wrong architecture
Finally discovered that this was due to an incompatibility between the 64 bit Eclipse/JVM and the 32 bit subversion-javahlbindings libraries I got from MacPorts. (Subclipse’s answer to just use those from CollabNet did not work for me as I had the same error with my https repository with CollabNet’s build of Subversion.)
This many hours in, I should have given up and returned to using svn from the command line as I had been doing for a few months, but I would not give up! I could not bear the idea of slogging through this whole upcoming project without IDE integration with source control.
The answer: I built the subversion-javahlbindings for 64 bit which required some learning about MacPorts.
To enable the x86_64 target in MacPorts:
In /opt/local/etc/macports.conf, add x86_64 as one of the universal targets:
universal_archs i386 x86_64
Then add the universal variant to the macports install of the subversion javahl bindings (I also needed no_bdb):
sudo port install subversion-javahlbindings +no_bdb +universal
This then required me to build a number of other dependencies with the +universal variant: zlib, cyrus-sasl2, ncurses, expat. I hope I haven’t broken a bunch of other macports software I am using by doing this. The nice thing about MacPorts, though, is that they only use MacPorts libraries and separate everything off into /opt/local. So this should not affect any other OS X stuff.
This may not be an issue at all with Snow Leopard; I don’t know. I am running Leopard and have not been compelled to upgrade. Thought about it a bit tonight.