Bugzilla – Bug 4630
RLS java client cannot load libaries through JNI on Mac
Last modified: 2008-01-29 22:25:35
You need to
before you can comment on or make changes to this bug.
This is with RLS from 4.0.2 patched slightly with bug 3253 patches and a couple
of (hopefully irrelevant) others.
I see this:
$ vds-plan helloworld.dax
Couldn't find flavor gcc32dbgpthr
Couldn't find flavor gcc32dbg
Couldn't find flavor gcc32pthr
Couldn't find flavor gcc32
Exception in thread "main" java.lang.UnsatisfiedLinkError: init
at org.globus.replica.rls.RLSClient.init(Native Method)
Turns out that in java on mac, libraries that are to be System.loadLibraried
need to have a .jnilib rather than .dylib extension (.dylib is the extension
for some other kind of dynamically loadable library; .so still seems to be used
for plain old shared libraries). So I typed this:
$ ln -s
and it works now.
The above ln hack is probably not the correct way to fix -- instead the build
process should probably be using the correct name in the first place.
Here's an (out-of-date) note about such:
I also forgot to mention that I had to set
(perhaps that should be done in globus-user-env.(c)sh)
This was on OS X 10.3, right?
no, 10.4.y (I don't recall the particular version of y that I was using at time
This bug is fixed by using the new RLS Client Java API in trunk (to be released
in GT 4.2)