Cygwin linking rules

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Cygwin linking rules
Date: 2018-09-29 15:35:47
Message-ID: 1056.1538235347@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-09-29 15:42:40 Re: Adding pipe support to pg_dump and pg_restore
Previous Message Stephen Frost 2018-09-29 15:03:22 Re: Adding pipe support to pg_dump and pg_restore