From: Marco Atzeri <marco.atzeri@gmail.com>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Cygwin linking rules
Date: Sat, 29 Sep 2018 20:13:25 +0200
Message-ID: <257c24fc-effb-871d-4529-e3ff2ea0d436@gmail.com> (raw)
In-Reply-To: <f82cc25e-3404-33b1-3a7b-93e5130e188e@2ndQuadrant.com>
References: <1056.1538235347@sss.pgh.pa.us>
<86419508-9d36-36a9-93ff-2a051af7d2e4@2ndQuadrant.com>
<f82cc25e-3404-33b1-3a7b-93e5130e188e@2ndQuadrant.com>
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/antivirusAttachments:cygwin-soversion.diff (text/plain, 1.2K) download--- origsrc/postgresql-9.4.2/src/Makefile.shlib 2015-05-20 00:33:58.000000000 +0200+++ src/Makefile.shlib 2015-05-27 23:01:09.379468300 +0200@@ -267,7 +267,7 @@ endif
ifeq ($(PORTNAME), cygwin)
LINK.shared = $(CC) -shared
ifdef SO_MAJOR_VERSION
- shlib = cyg$(NAME)$(DLSUFFIX)+ shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX)
endif
haslibarule = yes
endif
@@ -359,12 +359,9 @@ ifeq ($(PORTNAME), cygwin)
# Cygwin case
$(shlib): $(OBJS) | $(SHLIB_PREREQS)
- $(CC) $(CFLAGS) -shared -o $@ $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) $(LDAP_LIBS_BE)+ $(CC) $(CFLAGS) -shared -o $@ -Wl,--out-implib=$(stlib) $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) $(LDAP_LIBS_BE)-$(stlib): $(OBJS) | $(SHLIB_PREREQS)- rm -f $@- $(LINK.static) $@ $^- $(RANLIB) $@+$(stlib): $(shlib) ;
else
--- origsrc/postgresql-9.4.2/src/interfaces/libpq/Makefile 2015-05-20 00:33:58.000000000 +0200+++ src/interfaces/libpq/Makefile 2015-05-27 22:56:43.193200600 +0200@@ -45,7 +45,7 @@ OBJS += ip.o md5.o
OBJS += encnames.o wchar.o
ifeq ($(PORTNAME), cygwin)
-override shlib = cyg$(NAME)$(DLSUFFIX)+override shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX)
endif
ifeq ($(PORTNAME), win32)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: marco.atzeri@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Cygwin linking rules
In-Reply-To: <257c24fc-effb-871d-4529-e3ff2ea0d436@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox