Horton

Re: narwhal and PGDLLIMPORT

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Andres Freund <andres@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-02-04T22:29:54Z
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

Robert Haas <robertmhaas@gmail.com> writes:
> You know, I would really prefer to just stick a PGDLLIMPORT on this
> place and any others that need it, and any others that come up, than
> turn this into a political football.  Having to sprinkle PGDLLIMPORT
> on the handful of variables that are accessed by contrib modules is,
> indeed, annoying.

I'm not actually trying to turn this into a political football.  What
I want is a solution that we can trust, ie, that will allow us to
ship Windows code that's not broken.  We have failed to do so for at
least the past year, and not even known it.

I had been okay with the manual PGDLLIMPORT-sprinkling approach
(not happy with it, of course, but prepared to tolerate it) as long
as I believed the buildfarm would reliably tell us of the need for
it.  That assumption has now been conclusively disproven, though.
The question therefore becomes, what are we going to do instead?
"Keep on doing what we were doing" doesn't strike me as an acceptable
answer.

			regards, tom lane