A quick warning on the win32 build scripts

Lists: pgsql-hackers
From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: pgsql-hackers(at)postgresql(dot)org
Subject: A quick warning on the win32 build scripts
Date: 2010-10-05 12:36:24
Message-ID: 4CAB1BC8.5020700@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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(at)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(at)4 to _crashDumpHandler(at)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/


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: A quick warning on the win32 build scripts
Date: 2010-10-05 14:29:26
Message-ID: 23730.1286288966@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Craig Ringer <craig(at)postnewspapers(dot)com(dot)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


From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: A quick warning on the win32 build scripts
Date: 2010-12-20 16:56:34
Message-ID: AANLkTin3u9arocr14CA8nJtt+jcaWvTOPGj7Qsg9+zib@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

(Hello, very old thread)

On Tue, Oct 5, 2010 at 16:29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Craig Ringer <craig(at)postnewspapers(dot)com(dot)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/