Re: GCJ .jar to .so with native method

[Joe Hoffert <jhoffert at dre dot vanderbilt dot edu>]

Hi, Andrew.

On Tue, 2007-12-04 at 13:27 +0000, Andrew Haley wrote: 
> Joe Hoffert writes:
> 
>  > I'm running into some problems converting a Java library (i.e., .jar
>  > file) into a native shared library (i.e., .so file) and then using that
>  > library with g++. In particular, I have a native method in the .jar file
>  > that I can't figure out how to define to the linker's satisfaction. I'm
>  > using GCC 4.1.2 on Linux.
>  > 
>  > If I modify the gcjh-generated header file and define the native method
>  > inline (e.g., virtual void receive(JArray< jbyte > *, jint) {} ) the
>  > linker still complains about an undefined reference for the native
>  > method:
>  > 
>  > .//libricochet.so: undefined reference to `void
>  > multishot::examples::RicochetApp::receive(JArray<char>*, int)'
>  > collect2: ld returned 1 exit status
>  > 
>  > If I define the native method outside of the header file (e.g., in a C++
>  > source file like so:
>  > void multishot::examples::RicochetApp::receive(JArray< jbyte > *, jint)
>  > {} ) then the linker complains about a hidden symbol:
>  > 
>  > /usr/bin/ld: RicochetApp: hidden symbol `void
>  > multishot::examples::RicochetApp::receive(JArray<char>*, int)'
>  > in .obj/RicochetAppMain.o is referenced by DSO
>  > /usr/bin/ld: final link failed: Nonrepresentable section on output
>  > 
>  > Any ideas as to what I need to do to rectify my problem would be greatly
>  > appreciated.
> 
> This seems odd; we link C++ and Java code all the time.

Do you have a small example with C++ calling into Java (using the
invocation API) and then Java calling back to C++? I'm trying to
integrate a transport protocol written in Java with middleware written
in C++ so I need to call the protocol to send bytes and have the
protocol call C++ when it receives bytes.

> Is it possible for you to reduce your problem to a small test case?

I'll try to get a test case with a small .jar file. The test case I have
right now is fairly small although the .jar file isn't (i.e., 208031
bytes).

> Then we can see what's going wrong.  I think you're linking
> incorrectly, but at the moment that's just a wild guess.

Here is the gcj command I'm using to generate the .so library:

gcj -shared -fPIC -Wl,-Bsymbolic
~/Ricochet/jdk1.5_baseline/package/lib/ricochet.jar -o libricochet.so

Another possible wrinkle is that the .jar file was generated with JDK
1.5 rather than with gcj. (The Java source code uses generics quite a
bit which the gcj compiler doesn't like - at least for 4.1.2.) I'm
assuming byte codes are byte codes so this shouldn't be a problem but
perhaps this is naive on my part.

BTW, is there a later version of gch that might be able to handle the
generics in the Java source code?

Thanks for your help!

-Joe