[EMAIL PROTECTED] writes: > 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.
Please read this: http://catb.org/esr/faqs/smart-questions.html I am guessing that you get some link error, but it is difficult to help you when you don't tell *exactly* what the error is. > 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. I've never used 'dlltool'; reading its man page, I do not immediately see how you can tell from its output what is and what isn't in the export table of summarizer37.dll. Also, you mention destructors. If summarizer37.dll was not produced by the same version of g++ you are using, you can't expect to be able to link to destructors defined in it, because C++ code compiled with different compilers is not link-compatible. > 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? But you *are* interested in those symbols: your jsummarizer.obj references them (or else your link would not have failed). Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
