Re: Cygwin linking rules - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cygwin linking rules
Date
Msg-id 27791.1538500041@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cygwin linking rules  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: Cygwin linking rules  (Marco Atzeri <marco.atzeri@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: transction_timestamp() inside of procedures
Next
From:
Date:
Subject: NOTIFY and pg_notify performance when deduplicating notifications