Re: narwhal and PGDLLIMPORT

Andres Freund <andres@2ndquadrant.com>

From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Marco Atzeri <marco.atzeri@gmail.com>, pgsql-hackers@postgresql.org
Date: 2014-02-15T16:02:15Z
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 2014-02-15 10:59:17 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-02-15 10:16:50 -0500, Tom Lane wrote:
> >> The best thing probably is not to have the duplicate declarations on
> >> platforms that don't need 'em.  Unfortunately, I seem to recall that
> >> the current coding was arrived at to forestall link problems on weird
> >> platforms that *had* these symbols declared and yet we needed externs
> >> anyway.  We might have to do something as ugly as "#ifndef CYGWIN".
> 
> > Hm, according to a quick blame, they are there unconditionally since at
> > least 2000 (c.f. a70e74b06 moving them around). So it very well might be
> > that that reasoning isn't current anymore.
> 
> I don't have time right now to research it (have to go shovel snow),
> but I think that at least some of the issue was that we needed the
> externs when we force use of our src/port implementation.

I think that'd be solvable easy enough if we'd just always included pg's
getopt_long.h (or a new getopt.h) which properly deals with defining
them when included. That'd centralize all the magic and it'd overall get
rid of a ton of ifdefs and externs.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services