Hi, Andrew. On Tue, 2007-12-04 at 15:59 +0000, Andrew Haley wrote: > Joe Hoffert writes: > > Hi, Andrew. > > > > On Tue, 2007-12-04 at 15:16 +0000, Andrew Haley wrote: > > > > OK. I've attached a zip file with everything that should be needed. The > > gcj-commands file simply contains the gcj and gcjh commands I used to > > generate the .so library and the .h header files. > > Works for me: > > zorro:tmp $ gcjh -classpath ./ricochet.jar multishot.examples.RicochetApp > zorro:tmp $ gcj -shared -fPIC -Wl,-Bsymbolic ./ricochet.jar -o libricochet.so > zorro:tmp $ gcj RicochetAppMain.cpp -L. -lricochet -fPIC -lstdc++ > cc1plus: warning: command line option "-fbootclasspath=./:/usr/share/java/libgcj-4.1.2.jar" is valid for Java but not for C++ Ah! This is the missing piece for me. I was linking with g++. I was assuming since I had a .so library and .h headers I could treat the transformed .jar file like a C++ library. It never crossed my mind to compile the C++ file with gcj and link everything with gcj. I assume I will need to use gcj rather than g++ for all my C++ files. Is this correct? > zorro:tmp $ LD_LIBRARY_PATH=. ./a.out > Usage: RicochetApp GMS_id FDS_id startPortNumber [propertyString] > > You really need to call JvCreateJavaVM() first. In some other code I have I call JNI_CreateJavaVM. Is this different from JvCreateJavaVM and, if so, do you know how it differs? The prototype for JvCreateJavaVM doesn't exist in the jni.h file that I'm using. Adding this call raises some questions for me. Does this call add overhead (and/or footprint)? I was (seemingly naively) assuming that once the .jar file was converted to a .so file I was done with needing any Java support. This doesn't seem to be the case. Why is the JVM still needed? Are there any other calls I should add? > If this doesn't give you the same results, the problem is likely to be > that you need a new version of gcj. Thanks very much! You've been a tremendous help. I have struggled with this C++/Java integration for a while. -Joe
