On Aug 22, 10:39 pm, Paul Pluzhnikov <[EMAIL PROTECTED]>
wrote:
> [EMAIL PROTECTED] writes:
> > g++ -shared -o ${dllbuild}/jsummaraizer.dll ${cbuild}/jsummarizer.o $
> > {cbuild}/jsummarizer.def -L${librarydir} -lsummarizer37.dll
> ...
> > Any ideals?
>
> Yes, some of us have ideals, but you are probably looking for ideas.
>
> Please RTFM and understand the meaning of '-lfoo'.
>
> Hint: it makes the linker look for libfoo.{a,so} (and perhaps also
> libfoo.dll on Windows).
>
> Now substitute 'summarizer37.dll' for 'foo' and see if any of the
> resulting files (the first of which is 'libsummarizer37.dll.a')
> exist on your system.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.Ok, It appears to work the same as the java System.loadLibrary(<libname>) in that it is OS agnostic and finds an OS specific library. So I went to using "summarizer37". It now does not complain about not being able to find it. However, the reason that the library was included was to provide reference to a number of symbols (functions) I am using in jsummarizer.cc. Other functions (e.g. destructors) are still showing up as unresolved and therefore no dll is being produced. Using a dll tool, I can see that at least some of them are in the export table of summarizer37.dll or any of the other 4 dlls it depends on. Tried linking to all 5, no joy. Is there an option I need to be using the signals that I am not interessted in using those? Jim _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
