Paul Beardsley wrote:
>
> Nathan,
>
> Thanks for the reply.
>
> I just tried recompiling using -D_REENTRANT -fpic,
> but the same errors are occurring. When I run
> java, I get
You answered my point of curiosity about where the reference was coming
from... it's one of your templated classes referenced from within your
code. The only thing that springs to mind is to ask whether you're
following the conventions for supplying templated source code. It needs
to come from the .h file in which the declarations are made -- a common
technique is to include a nearby source file. You can see an example in
/usr/include/g++-2/std/bastring.h, which declares the classes, and
includes (at the end) bastring.cc which provides all of the templated
source.
In answer to your other question, I've used the STL, but not any of my
own templated classes, with JNI.
Nathan
>
> java MyApp
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
>/homes/pab/Vl/GuiJava/MyApp/Lib/libVl.so: /homes/pab/Vl/GuiJava/MyApp/Lib/libVl.so:
>undefined symbol: display__Ct14Vl_ImageHidden1Zt12Vl_PixelMono1ZUcP10Vl_Display
> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> at java.lang.ClassLoader.loadLibrary0(Compiled Code)
> at java.lang.ClassLoader.loadLibrary(Compiled Code)
> at java.lang.Runtime.loadLibrary0(Compiled Code)
> at java.lang.System.loadLibrary(Compiled Code)
> at Vlj_InterfaceMyApp.<clinit>(Vlj_InterfaceMyApp.java:16)
> at MyApp.main(Compiled Code)
>
> And when I run ldd, I get
>
> ldd -r Lib/libVl.so
> libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x400aa000)
> libm.so.6 => /lib/libm.so.6 (0x400ec000)
> libc.so.6 => /lib/libc.so.6 (0x40108000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
> undefined symbol: display__Ct14Vl_ImageHidden1Zt12Vl_PixelMono1ZUcP10Vl_Display
>(Lib/libVl.so)
> ...
> ... [about 100 more undefineds here] ...
> ...
>
> "Vl_ImageHidden" is one of my template classes. It
> is templated on a further template class
> "Vl_PixelMono<unsigned char>" in this application,
> and has a method called display which takes a parameter
> of type "Vl_Display*", so that's what is causing the
> unsatisfied link error.
>
> It is good to hear that you successfully
> linked to templates. Were the only
> templates in the STL,
> or did you link to your own template classes?
>
> Paul.
>
> Nathan Meyers writes:
> > Paul Beardsley wrote:
> > > I used "ldd -r libmylib.so" to look at my shared
> > > library and that also gave a list
> > > of undefined symbols, starting with the
> > > same symbol which Java lists as an unsatisfied link.
> >
> > And what might that symbol (or some of those symbols) be? That info
> > would help diagnose the problem.
> >
> > I've successfully built native components using the C++ STL and
> > templated classes, so there doesn't seem to be a generic template
> > problem here. My steps were:
> >
> > g++ -D_REENTRANT -fpic -c ...flags and files...
> > g++ -shared -o lib...
> >
> > and I'm using the g++ environment shipped with RH6.0.
> >
> > Nathan
> >
> >
> > >
> > > I just started working on Redhat 6.0 using
> > > jdk 1.2, and I would like to use a Java GUI
> > > linked to a C++ .so library (compiled with g++),
> > > communicating via the JNI.
> > >
> > > I successfully linked the Java GUI to the C++ library
> > > when no templates were used, but now I am linking to
> > > C++ classes which are templates, and I am getting
> > > unsatisfied link errors for the templated methods.
> > >
> > > I used "ldd -r libmylib.so" to look at my shared
> > > library and that also gave a list
> > > of undefined symbols, starting with the
> > > same symbol which Java lists as an unsatisfied link.
> > >
> > > So I guess I am not compiling the shared library
> > > with the correct compiler options. My link
> > > looks like this -
> > >
> > > g++ -shared File1.o ... FileN.o -o libVl.so
> > >
> > > I tried including -lc but that was no help.
> > > Can anyone tell me how to build this C++ shared
> > > library so it works with Java?
> > >
> > > Thanks a lot,
> > > Paul.
> > >
> > > ---------------------------------------------------------------------------
> > > Paul Beardsley email: [EMAIL PROTECTED]
> > > MERL - A Mitsubishi Electric Research Laboratory, tel: +(617) 621 7569
> > > 201 Broadway, Cambridge, MA 02139, USA fax: +(617) 621 7550
> > >
> > > ----------------------------------------------------------------------
> > > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
