Cygwin linking rules
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.
regards, tom lane
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 functionsWhat 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.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 functionsWhat 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
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 functionsWhat 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.dllFile Type: DLL
Image has the following dependencies:
postgres.exe
cygcrypto-1.0.0.dll
cygwin1.dll
cygssl-1.0.0.dll
KERNEL32.dllI'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
Attachments:
cygwin-soversion.difftext/plain; charset=UTF-8; name=cygwin-soversion.diffDownload
--- 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)
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 functionsWhat 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.dllFile Type: DLL
Image has the following dependencies:
postgres.exe
cygcrypto-1.0.0.dll
cygwin1.dll
cygssl-1.0.0.dll
KERNEL32.dllI'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
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
Not sure where to go from here.
What would happen if we stopped building libpq.a, so that the
linker didn't have any choice about what to do?
regards, tom lane
On 09/29/2018 04:06 PM, Tom Lane wrote:
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
Not sure where to go from here.
What would happen if we stopped building libpq.a, so that the
linker didn't have any choice about what to do?
I will test Marco's patch, which I think does that, tomorrow.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 09/29/2018 02:13 PM, Marco Atzeri wrote:
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_64I 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
Yes. So there are a couple of things here. First, the dll has
SO_MAJORVERSION in the name. And second it stops building any static
libraries and instead builds windows import libraries with names like
lippq.a.
I've tested this on both HEAD and REL9_3_STABLE and it works fine.
I think we should apply this to HEAD. If it's not too late it would
probably be a good thing for release 11 - would need a release note.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
On 09/29/2018 02:13 PM, Marco Atzeri wrote:
[ proposed patch ]
Yes. So there are a couple of things here. First, the dll has
SO_MAJORVERSION in the name. And second it stops building any static
libraries and instead builds windows import libraries with names like
lippq.a.
I'm pretty much -1 on adding SO_MAJORVERSION to the library names.
It seems like it will cause churn to library users without really
accomplishing much, because when was the last time we changed the
SO_MAJORVERSION of anything?
I'd suggest that if we ever do change libpq's SO_MAJORVERSION,
that would be the time to append the suffix (so we'd go from libpq.dll
to libpq-6.dll). For now, let's not fix what isn't broken.
However, the .a linking definitely is broken, and if this way
of building fixes it, that's great. I do not have the ability
to test it, but we can throw it into the buildfarm to see what
happens.
I think we should apply this to HEAD. If it's not too late it would
probably be a good thing for release 11 - would need a release note.
I think it's too late for 11; we're too close to RC1, and besides
the problem this is fixing doesn't seem to manifest before my
recent port/common library changes. (If that's not so, maybe it
qualifies as a bug fix for back branches; but it seems rather
high risk.)
regards, tom lane
Marco Atzeri <marco.atzeri@gmail.com> writes:
[ cygwin-soversion.diff ]
Oh, one other minor comment on this patch: the rule for the "stlib"
must not be just
$(stlib): $(shlib) ;
Something like this would work:
$(stlib): $(shlib)
touch $@
See e.g. the AIX case in Makefile.shlib, which is doing about the
same thing.
regards, tom lane
Am 02.10.2018 um 19:07 schrieb Tom Lane:
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
On 09/29/2018 02:13 PM, Marco Atzeri wrote:
[ proposed patch ]
Yes. So there are a couple of things here. First, the dll has
SO_MAJORVERSION in the name. And second it stops building any static
libraries and instead builds windows import libraries with names like
lippq.a.I'm pretty much -1 on adding SO_MAJORVERSION to the library names.
It seems like it will cause churn to library users without really
accomplishing much, because when was the last time we changed the
SO_MAJORVERSION of anything?I'd suggest that if we ever do change libpq's SO_MAJORVERSION,
that would be the time to append the suffix (so we'd go from libpq.dll
to libpq-6.dll). For now, let's not fix what isn't broken.
On cygwin the library is cygpq-5.dll by long time;
around 2013 with 9.2.x we standardized to have the
SO_MAJORVERSION in the lib name as all the other
packages
https://cygwin.com/packages/x86_64/libpq5/libpq5-10.5-1
same as on Unix/Linux
https://packages.debian.org/sid/amd64/libpq5/filelist
However, the .a linking definitely is broken, and if this way
of building fixes it, that's great. I do not have the ability
to test it, but we can throw it into the buildfarm to see what
happens.I think we should apply this to HEAD. If it's not too late it would
probably be a good thing for release 11 - would need a release note.I think it's too late for 11; we're too close to RC1, and besides
the problem this is fixing doesn't seem to manifest before my
recent port/common library changes. (If that's not so, maybe it
qualifies as a bug fix for back branches; but it seems rather
high risk.)
No problem. It works for my cygwin package release
but I could have broken something around and it need to be tested.
regards, tom lane
Regards
Marco
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus