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
