Обсуждение: A quick warning on the win32 build scripts

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/

Craig Ringer <craig@postnewspapers.com.au> writes:
> 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.

Um, so can't we fix that?  It seems like a rather basic expectation of a
build process that it will rebuild dependent files when needed.

> 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.

This seems to me to be similar to proposing that we all write assembly
language because somebody's build system can't be trusted to regenerate
.o files when .c files are changed.
        regards, tom lane

(Hello, very old thread)

On Tue, Oct 5, 2010 at 16:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Craig Ringer <craig@postnewspapers.com.au> writes:
>> 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.
>
> Um, so can't we fix that?  It seems like a rather basic expectation of a
> build process that it will rebuild dependent files when needed.

Does anybody have an idea of *how* to actually do that?

My first thought was to just generate a DEF file whenever any of the
object files have changed, which could be a simple date comparison.
However, generating the DEF file is *really* expensive and slow, so
this would make rebuilding anything that *doesn't* add or remove an
entrypoint unacceptably slow..

Can someone think of a way to do this without having to dump the list
of exports from each and every object file?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/