Horton

Re: narwhal and PGDLLIMPORT

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Craig Ringer <craig@2ndquadrant.com>, Ashesh Vashi <ashesh.vashi@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2014-02-03T14:25:57Z
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

Andres Freund <andres@2ndquadrant.com> writes:
> What about the completely crazy thing of simply redefining export to
> include the declspec on windows for backend build? That will possibly
> blow up the size of the .def files et al a bit, but I have little mercy
> with that.

You mean "#define extern extern PGDLLIMPORT" ?  What will that do to
function declarations that have "extern"?  Are we sure C compilers
are smart enough to not go into an infinite loop on such a macro?

Anyway, narwhal's latest results thicken the plot even more.
How come pg_buffercache has been building OK on the other
Windows critters, when MainLWLockArray lacks PGDLLIMPORT?
That lets out the theory about linking to libpq having something
to do with it.

			regards, tom lane