Horton

Re: narwhal and PGDLLIMPORT

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dave Page <dpage@pgadmin.org>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Hiroshi Inoue <inoue@tpf.co.jp>, Andrew Dunstan <andrew@dunslane.net>, Craig Ringer <craig@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-10-14T23:07:17Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. MinGW: Link with shell32.dll instead of shfolder.dll.

  2. Centralize getopt-related declarations in a new header file pg_getopt.h.

  3. Get rid of use of dlltool in Mingw builds.

  4. Export a few more symbols required for test_shm_mq module.

  5. Export set_latch_on_sigusr1 symbol for Windows.

  6. Use SHGetFolderPath instead of SHGetSpecialFolderPath to find the

Dave Page <dpage@pgadmin.org> writes:
> On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think we're hoping that somebody will step up and investigate how
>> narwhal's problem might be fixed.  However, the machine's owner (Dave)
>> doesn't appear to have the time/interest to do that.

> It's a time issue right now I'm afraid (always interested in fixing bugs).

> However, if "fixing" it comes down to upgrading the seriously old
> compiler and toolchain on that box (which frankly is so obsolete, I
> can't see why anyone would want to use anything like it these days),
> then I think the best option is to retire it, and replace it with
> Windows 2012R2 and a modern release of MinGW/Msys which is far more
> likely to be similar to what someone would want to use at present.

No argument here.  I would kind of like to have more than zero
understanding of *why* it's failing, just in case there's more to it
than "oh, probably a bug in this old toolchain".  But finding that out
might well take significant time, and in the end not tell us anything
very useful.

> Does anyone really think there's a good reason to keep maintaining
> such an obsolete animal?

Is it likely that anyone is still using Windows 2003 in the field?
A possible compromise is to update the toolchain but stay on the
same OS release, so that we still have testing that's relevant to
people using older OS releases.

			regards, tom lane