On 01/08/2016 02:11 AM, Michael Paquier wrote:
> On Fri, Jan 8, 2016 at 3:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Michael Paquier <michael.paquier@gmail.com> writes:
>>> On Fri, Jan 8, 2016 at 11:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> brolga is still unhappy:
>>> ... Now, backbranches are proving that compiling pg_ctl.c with those
>>> routines copied in it actually works fine, so based on my limited time
>>> for the next couple of days, it may be better to just revert the patch
>>> entirely on HEAD and apply what has been pushed into back branches to
>>> stabilize the buildfarm, this will address the bug entirely. And it is
>>> no good to keep the buildfarm red for long,
>> Hm, narwhal just reported in green, which I was not expecting, and so did
>> frogmouth. So brolga seems like an outlier. I think reverting might be
>> an overreaction. At this point the question is more like "how is brolga
>> different from the other non-MSVC Windows critters?". Perhaps Andrew
>> can offer some insight.
> That's a good sign at least :)
>
> Looking at the logs, the main difference is that win32security.c is
> not compiled in -lpgport for cygwin, and cygwin goes through
> src/include/port/win32.h to refer to some routines, so I would think
> that the correct fix is to add win32security.c to the list of OBJS for
> cygwin. So the attached is correct perhaps? That's a blind fix I don't
> have cygwin set up on my machines now.
I'll test it when I get a moment. Thanks for the patch.
I see this service code goes back probably to the first commit of
pg_ctl.c, which means it's going to have been either my fault or Bruce's
:-) TBH I'm not sure how to run postgres as a service on Cygwin. In
general I would expect it to be via cygrunsrv, like other services I do
actually run (cron and cygserver), rather than via pg_ctl. Anyway, for
now lets see if we can get it building again.
cheers
andrew