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)
        at org.globus.replica.rls.RLSClient.<clinit>(RLSClient.java:862)
        at org.griphyn.cPlanner.rls.RLSQuery.<init>(RLSQuery.java:143)
        at org.griphyn.cPlanner.engine.RLSEngine.<init>(RLSEngine.java:244)

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
/Users/benc/work/gt-4.0.2/lib/libglobus_rls_client_jni_gcc32dbgpthr.dylib
/Users/benc/work/gt-4.0.2/lib/libglobus_rls_client_jni_gcc32dbgpthr.jnilib

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:
http://developer.apple.com/documentation/Java/Conceptual/Java131Development/overview/chapter_2_section_5.html#//apple_ref/doc/uid/TP30000705-TPXREF114