I would expect that at least some (and probably all) of those "unresolved external symbol" errors would be resolved by your libexpat.lib ... but apparently that's not the case.
Is your libexpat.lib an import lib for a dll ?
If so, then I think it should resolve those symbols. But, if it's a static library, then it won't resolve those symbols (because the "imp" part will be missing).
I guess another possibility is that your libexpat.lib is too old, but I think that's unlikely.
Try doing a search of libexpat.lib for the strings "XML_SetCommentHandler", "imp__XML_SetCommentHandler" and "imp_XML_SetCommentHandler". Are *any* of those strings found ? If so, which one(s) ?
It's the (first and) last of those 3 that needs to be found for you. However, in the libexpat import library that I looked at, it was the first 2 that could be found - so I think there's at least a chance that the difference in the number of underscores (1 versus 2) between the "imp" and the "XML" is bringing you undone.
If "imp_XML_SetCommentHandler" *does* exist in libexpat.lib, how many leading underscores come before "imp" ?
Cheers,
Rob | [reply] |
Use MS dumpbin on the .lib file. Much cleaner than use a text editor.
| [reply] |
I have first and last occurance in my lib file,please help how to resolve this issue
| [reply] |
I have first and last occurance in my lib file,please help how to resolve this issue
Do you also have all of the "unresolved external symbol" errors in between the first and last occurrences ?
Could you please provide the output of running perl -V
Are you actually using Visual Studio 10 as your C compiler ? (Assuming that you are using a Microsoft Compiler, the output of running cl /? might also be useful.)
Cheers,
Rob
| [reply]
[d/l]
[select] |
| [reply] |
I found this thread much later and think I might have something to add.
I got similar output:
Expat.obj : error LNK2001: unresolved external symbol __imp_XML_SetEnd
+DoctypeDeclHandler
Expat.obj : error LNK2001: unresolved external symbol __imp_XML_GetBas
+e
Expat.obj : error LNK2001: unresolved external symbol __imp_XML_SetEle
+mentDeclHandler
Expat.obj : error LNK2001: unresolved external symbol __imp_XML_Defaul
+tCurrent
Expat.obj : error LNK2001: unresolved external symbol __imp_XML_SetSta
+rtCdataSectionHandler
...
When I searched for one of the symbol in the libexpat.lib file, I found something interesting.
$ grep _imp__XML_SetCommentHandler libexpat.lib
Binary file libexpat.lib matches
$ grep __imp_XML_SetCommentHandler libexpat.lib
Exit 1
The short of it is that the symbol name is not correct. I think the toolchain (gcc, other VC version) used to build libexpat.lib was different from the toolchain that I am using to build XML::Parser::Expat and that is why the link is failing.
I have a theory on what is actually happening, but it is only a theory, so take it for what it is...
The libexpat.lib contains a XML_SetCommentHandler function that knows how to load the libexpat.dll and then call a differently named version of the function that resides in the DLL. This naming is the root problem.
When the libexpat.lib was compiled, the prototype of the DLL version of the function had extern "c", and some "declspec" keyword, added to the name. The use of extern "c" prepends a "_" to the symbol name. The use of "declspec" prepends a "_imp_" to the symbol name.
When the toolchain used to build libexpat.dll built the function, it honored the order of the extern "c" and "declspec" differently than the toolchain that I am using to build/link the libexpat.lib.
| [reply]
[d/l]
[select] |
The error text is on my scratchpad. Please guide me on this issue. It should be in your post and not in your scratchpad.
| [reply] |