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: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2014-02-02T06:58: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 Sun, Feb 2, 2014 at 1:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I happened to notice today that the owner of buildfarm member narwhal
> is trying to revive it after a long time offline, but it's failing in
> the 9.3 branch (and not attempting to build HEAD, yet).  The cause
> appears to be that contrib/postgres_fdw is referencing the DateStyle
> and IntervalStyle variables, which aren't marked PGDLLIMPORT.
> Hm, well, that would be an easy change ... but that code was committed
> last March.  How is it that we didn't notice this long ago?
>
> What this seems to indicate is that narwhal is the only buildfarm
> animal that has a need for PGDLLIMPORT marks on global variables that
> are referenced by extensions.  Furthermore, nobody has attempted to
> build 9.3 on a platform that needs that (or at least they've not
> reported failure to us).
>
> According to the buildfarm database, narwhal is running a gcc build on
> Windows 2003.  That hardly seems like a mainstream use case.  I could
> believe that it might be of interest to developers, but clearly no
> developers are actually running such a build.
>
> I think we should give serious consideration to desupporting this
> combination so that we can get rid of the plague of PGDLLIMPORT
> marks.  Obviously this would depend on confirming that there are
> no more-interesting Windows build methods that require it --- but
> if there are any, I'd sure demand that there be an active buildfarm
> instance to keep us from breaking the case again in future.

No objection here - though I should point out that it's not been
offline for a long time (aside from a couple of weeks in January) -
it's been happily building most pre-9.2 branches for ages. 9.1 seems
to be stuck, along with HEAD, and I forgot to add 9.3. I'm in the
process of cleaning that up as time allows, but am happy to drop it
instead if we no longer want to support anything that old. We
certainly don't use anything resembling that config for the EDB
installer builds.

I'm happy to replace it with something newer as time allows - what do
we consider to be the biggest gap? I have an MSDN subscription, so can
do any versions of Windows or VC++ (and obviously Mingw).

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

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