Re: Cygwin linking rules

Am 29.09.2018 um 19:03 schrieb Andrew Dunstan:
> 
> 
> 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.
> 
> 
> cheers
> 
> andrew

building from git and using the attached patch that is used for all 
cygwin packages on latest cygwin

$ uname -svrm
CYGWIN_NT-10.0 2.11.1(0.329/5/3) 2018-09-05 10:24 x86_64

I do not see the problem

============== creating database "contrib_regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries        ==============
test paths                        ... ok
test dblink                       ... ok
============== shutting down postmaster               ==============


  $ objdump -x usr/lib/postgresql/dblink.dll |grep "DLL Name:"
         DLL Name: postgres.exe
         DLL Name: cygpq-5.dll
         DLL Name: cygwin1.dll
         DLL Name: KERNEL32.dll


I am wondering if I am testing the same
-----------------------------------------------
$ git log |head
commit 8bddc864000f56d396621d4ad0f13e8e1872ddf5
Author: Stephen Frost <sfrost@snowman.net>
Date:   Fri Sep 28 19:04:50 2018 -0400

     Add application_name to connection authorized msg

     The connection authorized message has quite a bit of useful information
     in it, but didn't include the application_name (when provided), so 
let's
     add that as it can be very useful.
---------------------------------------------------



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus