Re: narwhal and PGDLLIMPORT - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: narwhal and PGDLLIMPORT
Date
Msg-id CAA4eK1K17XmK8bQV3ZgMB8wDRMvA8TG=GFcm+DDXKh-PUx6QNQ@mail.gmail.com
Whole thread Raw
In response to Re: narwhal and PGDLLIMPORT  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: narwhal and PGDLLIMPORT  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Mon, Feb 10, 2014 at 8:51 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 02/05/2014 01:52 PM, Tom Lane wrote:
>> Craig Ringer <craig@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?


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: New option for pg_basebackup, to specify a different directory for pg_xlog
Next
From: Craig Ringer
Date:
Subject: Re: narwhal and PGDLLIMPORT