Re: Cygwin linking rules
От | Andrew Dunstan |
---|---|
Тема | Re: Cygwin linking rules |
Дата | |
Msg-id | 86419508-9d36-36a9-93ff-2a051af7d2e4@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Cygwin linking rules (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Cygwin linking rules
|
Список | pgsql-hackers |
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. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: