Re: [HACKERS] A quick warning on the win32 build scripts
(Hello, very old thread) On Tue, Oct 5, 2010 at 16:29, Tom Lane t...@sss.pgh.pa.us wrote: Craig Ringer cr...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 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
Re: [HACKERS] A quick warning on the win32 build scripts
Craig Ringer cr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
