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 crashdumphand...@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 crashdumphand...@4 to _crashdumphand...@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/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to