logo
  • About

Using JavaHL with Eclipse on OS X

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-1.0.0.0.dylib:  no suitable image found.  Did find:  /opt/local/lib/libsvnjavahl-1.0.0.0.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.

8 comments

  • Tom Harrison Jr January 3, 2011 at 12:45 am -

    As of January 2011… I upgraded MacPorts as indicated (a painful, slow but documented process) to Snow Leopard last year. In particular, they recommend editing the /opt/local/macports.conf file to remove references to 32-bit architectures. After rebuilding, all ports were rebuilt as 64-bit versions. Then recently I installed the javahl bindings to get Subclipse to work, and with no variants or directives (no +no_bsd, and no +universal) when done, it worked without complaint.

    Well, that’s after dealing with some bug with ncurses (use the “clean” command for ncurses and ncursesw), and then after downloading the developer JDK from Apple’s developer site. None of it was hard, just a matter of time.

  • Nigel October 27, 2011 at 2:25 pm -

    Thank you! This helped install Subclipse package on Mac OS X Lion.

  • Luo Chunhui December 25, 2011 at 12:30 pm -

    Thanks, It works in Mac OS X lion.

  • mitek March 4, 2012 at 6:16 am -

    Thank you! The only useful post I was able to find.

    CollabNet guys tell describe the problem and recommend downloading binaries 1.6.x. as the only possible solution.
    C’mon!

  • great July 26, 2012 at 5:48 pm -

    Thank you! Took a while, but worked great!

Leave a Reply

Your email address will not be published. Required fields are marked *

Calendar

March 2023
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  
« Nov    

Archives

  • November 2014
  • September 2014
  • March 2014
  • February 2014
  • September 2013
  • March 2011
  • January 2011
  • October 2010
  • August 2010
  • July 2010
  • April 2009
  • March 2009
  • January 2009
  • September 2008

Categories

  • Clojure
  • ClojureBridge
  • Conferences
  • Game development
  • Uncategorized
  • Vim

Copyright Bridget 2023 - Theme by Theme in Progress