On 09/29/2018 01:03 PM, Andrew Dunstan wrote:
>
>
> On 09/29/2018 12:09 PM, Andrew Dunstan wrote:
>>
>>
>> On 09/29/2018 11:35 AM, Tom Lane wrote:
>>> Most of the buildfarm is now happy with the changes I made to have
>>> libpq + ecpg get src/port and src/common files via libraries ...
>>> but lorikeet isn't. It gets through the core regression tests fine
>>> (so libpq, per se, works), but contrib/dblink fails:
>>>
>>> ! ERROR: could not establish connection
>>> ! DETAIL: libpq is incorrectly linked to backend functions
>>>
>>> What this means is that libpq is calling the backend version of
>>> src/common/link-canary.c rather than the frontend version.
>>> Why would it do the right thing normally and the wrong thing in dblink?
>>>
>>> I can think of a few theories but I lack the ability to investigate:
>>>
>>> 1. Maybe the dblink.dll build is pulling in libpq.a rather than
>>> establishing a reference to libpq.dll. If so, the wrong things would
>>> happen because libpq.a won't contain the src/common/ files that
>>> libpq needs. (It seems like libpq.a is an active hazard given
>>> this. Why are we building it at all?)
>>>
>>> 2. Maybe we need a --version-script option or something equivalent
>>> to get libpq.dll's references to be preferentially resolved internally
>>> rather than to the backend. But this doesn't really explain why it
>>> worked properly before.
>>>
>>>
>>
>>
>>
>> I will see if I can determine if 1) is the cause. I don't know
>> enough, or in fact anything, about 2), so don;t know that I can help
>> there without advice.
>>
>>
>
>
>
> It certainly looks like it's not linked to libpq.dll:
>
> Microsoft (R) COFF/PE Dumper Version 14.15.26726.0
> Copyright (C) Microsoft Corporation. All rights reserved.
>
>
> Dump of file
> \cygwin64\home\andrew\\bf64\root\HEAD\inst\lib\postgresql\dblink.dll
>
> File Type: DLL
>
> Image has the following dependencies:
>
> postgres.exe
> cygcrypto-1.0.0.dll
> cygwin1.dll
> cygssl-1.0.0.dll
> KERNEL32.dll
>
>
> I'll build an earlier version to do a comparison just to make sure
> we're seeing the right thing.
>
>
>
Hmm. Getting the same result from REL_10_STABLE.
Not sure where to go from here.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services