This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCJ .jar to .so with native method


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]