Hi Scott
I have no experience with Mac OS. However since your problems seem
similar to my experience with Java on linux, I have replied based on
the understanding that OS X shares significant similarities to linux.
If you note anything that is different, please correct me.
On Tue, 31 May 2005 01:18 am, Scott Palmer wrote:
> On May 30, 2005, at 9:43 AM, Mark Phippard wrote:
> > Subversion installs its libraries in the correct locations but Java
> > doesn't
> > look in that location to load the libraries.
>
> Subversion must have a very interesting interpretation of "correct".
> If the location was correct it would work, or is my concept of
> "correct" warped by my insistence on using logic :) ?
My understanding is that Sun's Java only looks for jni libraries in the
directories specified by the system property java.library.path. If not
set, it uses defaults values. On windows these defaults include the
entire path. On my Debian box path is ignored, LD_LIBRARY_PATH is
added if set (by default on this box it is not set), otherwise java
uses only paths internal to the jdk.
To find out which directories java on OS X includes see
http://subclipse.tigris.org/servlets/ReadMsg?list=users&msgNo=2751
Directories internal to the jdk are not a sensible place for subversion
to install a native library. The native library would need to be
copied/linked for each installed jdk/jre. (This box has 3 official
jdks + 4 open-source java implementations). If I install a new jdk,
then the new jdk won't include the jni libraries. If I rm -rf the old
jdk, then I've deleted the jni libraries.
> > Since the Metissian packages just work out of the box, I suspect
> > that there
> > installer must create symlinks in some OS X folder that causes the
> > libraries to seen by Java. Perhaps an email on the Subversion
> > users@ list
> > could get more details about what they do. And yes, perhaps the
> > Subversion
> > make script could be enhanced to create these symlinks too.
>
> Yes, I think that is the proper solution. "make install-javahl" by
> necessity should leaving things in a state where the JNI library will
> load successfully by the Java runtime.
>
In an ideal world it would.
IMO the 'proper' solution is to convince Sun to fix java so that it uses
the standard system methods to find jni libraries.
The alternative solutions I see are:
i) set LD_LIBRARY_PATH at login. Install jni libs to a directory in
LD_LIBRARY_PATH;
ii) tell java where to look by using a wrapper script to launch eclipse
(eg either setting LD_LIBRARY_PATH=<path-to-jni-libs> or
-Djava.library.path=<path-to-jni-libs>);
iii) or manually copy / link the necessary libs the necessary libs to an
appropriate directory inside eclipse (eclipse has already added some
directories to java.library.path to find the SWT libs);
iv) or manually copy / link the necessary libs somewhere java looks for
each installed jdk;
v) or find some way for javahl/subclipse to tell java at run-time where
to find the jni libs.
> I built Subversion 1.2.x on OS X. Did "make install" and make
> "install-javahl". Both appeared to complete without any errors.
> However, the Subclipse plugin is unable to load the javahl library,
> presumably because various bits of native code are not in a place
> accessible by the Java runtime. I interpret this as "make install-
> javahl" not doing it's job adequately.
>
Any compile time only solutions will probably have problems whenever
jdks/jres are added removed after installing subversion.
Hope this helps.
Andrew V.
Received on Tue May 31 03:59:24 2005