Thank you Nathan,
You were right. I thought if you use C++ files the linker picks up
correct libraries automatically - not yet.
Anyway, your answer reminds me how great our listserver is.
Thank you again,
Jacob Nikom
Nathan Meyers wrote:
>
> On Fri, Nov 19, 1999 at 06:44:48PM -0500, Jacob Nikom wrote:
> > I am writing JNI application called MainPanel using Java, C++ and
> > a bit of C. It compiles and links without problem, but when I run
> > it, it crushes with the message...
>
> My guess is that you linked your shared library using gcc instead of
> g++, and so it lacks a reference to the C++ library that defines
> cout. If you run "ldd" on the shared library and you see no reference
> to a library named libstdc++, that's the culprit. Try linking your
> .so with g++.
>
> > I always thought all symbols should be found (resolved) during the
> > linking stage. If there is no complains from the linker, there should
> > not be any complains during runtime. Looks like it is not so, but why?
>
> I don't believe the linker complains about unresolved references in
> shared libraries. The rationale, I guess, is that the missing piece will
> come from the application or some other shared library.
>
> Nathan
>
> On Fri, Nov 19, 1999 at 06:44:48PM -0500, Jacob Nikom wrote:
> > Hi,
> >
> > I am writing JNI application called MainPanel using Java, C++ and
> > a bit of C. It compiles and links without problem, but when I run
> > it, it crushes with the message:
> >
> > prompt>java -green MainPanel pixelbuf
> > Exception in thread "main" java.lang.UnsatisfiedLinkError:
> > /homes/nikom/work/libStereoImageTransform.so:
> > undefined symbol: cout
> > 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 MainPanel.<clinit>(MainPanel.java:13)
> > make: *** [go] Error 1
> >
> > Here is the code of MainPanel.java:
> >
> > 1 import java.awt.*;
> > 2 import java.awt.event.*;
> > 3 import javax.swing.*;
> > 4
> > 5 class MainPanel extends JPanel
> > 6 {
> > 7
> > 8 public static synchronized native void
> > 9 ImageTransform(int[] x1Array, int[] y1Array, int[]
> > x2Array, int[] y2Array);
> > 10
> > 11 static
> > 12 {
> > --> 13 System.loadLibrary("StereoImageTransform");
> > 14 }
> > 15
> > 16 static ImagePanel imagePanel;
> > 17
> > ......................................................
> >
> > The structure of this JNI application is very simple:
> >
> > +------------+
> > | Java code |
> > +------------+
> > | ^
> > v |
> > +------------+
> > | C wrapper |
> > +------------+
> > | ^
> > v |
> > +------------+
> > | C++ code |
> > +------------+
> >
> > I always thought all symbols should be found (resolved) during the
> > linking stage. If there is no complains from the linker, there should
> > not be any complains during runtime. Looks like it is not so, but why?
> > Do you have any suggestions how to fix or investigate the problem?
> >
> > Thank you,
> >
> > Jacob Nikom
> >
> >
> > ----------------------------------------------------------------------
> > 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]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
