On 02/10/2014 01:59 PM, Amit Kapila wrote: > On Mon, Feb 10, 2014 at 8:51 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: >> On 02/05/2014 01:52 PM, Tom Lane wrote: >>> Craig Ringer <cr...@2ndquadrant.com> writes: >>>> On 02/05/2014 06:29 AM, Tom Lane wrote: >>>>> I had been okay with the manual PGDLLIMPORT-sprinkling approach >>>>> (not happy with it, of course, but prepared to tolerate it) as long >>>>> as I believed the buildfarm would reliably tell us of the need for >>>>> it. That assumption has now been conclusively disproven, though. >>> >>>> I'm kind of horrified that the dynamic linker doesn't throw its toys >>>> when it sees this. >>> >>> Indeed :-(. >>> >>> The truly strange part of this is that it seems that the one Windows >>> buildfarm member that's telling the truth (or most nearly so, anyway) >>> is narwhal, which appears to have the oldest and cruftiest toolchain >>> of the lot. I'd really like to come out the other end of this >>> investigation with a clear understanding of why the newer toolchains >>> are failing to report a link problem, and yet not building working >>> executables. >> >> For MSVC, here's a patch that makes gendef.pl emit DATA annotations for >> global var exports. > > Is this change intended to avoid the usage of __declspec (dllimport) for > global variables? > > Won't it increase the build time for Windows as it seems to me you > are traversing each symbol file to find the global vars?
gendefs.pl does that anyway. This change just annotates emitted entries with "DATA" if they're exported vars. It takes a couple of seconds to run gendefs.pl, so I don't think it's really a big concern. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers