Hi
I lost a few hours trying to nut out an issue with the crash handler I'm
building as a contrib module. Having found out what was going on, I want
to post it here to help Google find it if others hit it later.
Compilation of the contrib module was failing during linkage with
bizarre errors about "LNK2001: unresolved external symbol
crashDumpHandler@4 ", where crashDumpHandler is the function I'm
registring with the handler. This didn't make much sense, because
crashDumpHandler wasn't declared __declspec(dllexport) and was defined
anyway.
The cause turns out to be the automatic .DEF file generation. It skips
DEF file generation if a DEF file already exists, even if the
object/sources are newer than the existing DEF file. If you've changed a
function signature, made a previously-exported function static, changed
the calling convention of a function, etc then you'll get linkage errors.
In my case, I'd corrected the function to be declared WINAPI (just a
macro for "__stdcall", setting the calling convention), which changed
the mangled name from crashDumpHandler@4 to _crashDumpHandler@4 , thus
causing a linkage error.
Because most win32 projects use explicit exports rather than generating
DEF files, I didn't even know to look for this.
This makes me even more in favour of applying the patch proposed a while
ago, to add explicit API exports to all the contrib modules. That'd
permit automatic DEF generation to be disabled, and would reduce the
size of the exported symbol tables from contrib modules - which is good
from a dynamic linking performance point of view.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
