Re: GCJ .jar to .so with native method

[Andrew Haley <aph at redhat dot com>]

Joe Hoffert writes:
 > 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?

I don't think it matters.  I could have done this instead:

zorro:tmp $ g++ RicochetAppMain.cpp -L. -lricochet -fPIC  -lgcj

 > > 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.

No, but it is included.  You must call JvCreateJavaVM() as the very
first call into libgcj.  This is *really* important.

 > 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?

There's a ton of stuff: threads, garbage collection, and of course the
entire Java runtime library.

 > Are there any other calls I should add?

I can't think of any.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903