Joe Hoffert writes:
> 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++?
No. I have a really big one, libgcj itself.
> 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).
That is plenty small enough.
> > 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
I thought you were linking the jar with some native code. If so, the
native code must appear on that line also.
> 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.
It might be OK, but later versions of gcj (that, sadly are still not
yet officially released!) handle Java 1.5 much better.
> BTW, is there a later version of gch that might be able to handle the
> generics in the Java source code?
It's quite hard to handle generics in gcjh, but for the purposes we
use native methods for it works well enough.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
