Horton

Re: narwhal and PGDLLIMPORT

Dave Page <dpage@pgadmin.org>

View thread
From: Dave Page <dpage@pgadmin.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
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-14T22:44:55Z
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

On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> It seems we left this in broken state.  Do we need to do more here to
>> fix narwhal, or do we want to retire narwhal now?  Something else?  Are
>> we waiting on someone in particular to do something specific?
>
> 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.  That means that
> our realistic choices are to retire narwhal or revert the linker changes
> that broke it.  Since those linker changes were intended to help expose
> missing-PGDLLIMPORT bugs, I don't much care for the second alternative.

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.

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

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company