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
...
[download]

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
[download]

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.

Comment on Re: XMl-Parser build failed on windows X64 with VStuido10 Select or Download Code