Horton

Re: narwhal and PGDLLIMPORT

Andres Freund <andres@2ndquadrant.com>

View thread
From: Andres Freund <andres@2ndquadrant.com>
To: Andrew Dunstan <andrew@dunslane.net>,Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-02-04T16:30:46Z
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 February 4, 2014 5:06:52 PM CET, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>On 02/04/2014 10:43 AM, Tom Lane wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>>> On 2014-02-04 02:10:47 -0500, Tom Lane wrote:
>>>> Meh.  It might be that the DateStyle usage in postgres_fdw would
>>>> accidentally fail to malfunction if it saw a bogus value of the
>variable.
>>>> But it's hard to believe that this would be true of
>MainLWLockArray.
>>> There's not that much lwlock usage in contrib. It's just
>>> pg_stat_statements and pg_buffercache. Neither has tests... So it
>very
>>> well could be that breakage simply hasn't been observed.
>> Hm, you're right --- I'd have thought there were more of those.
>>
>> Ugh.  This problem was bad enough when I thought that it would only
>lead
>> to link-time errors detectable in the buildfarm.  If it can lead to
>errors
>> only observable at runtime --- and maybe not obvious even then ---
>then
>> I think we *have to* do something about it.  By that I mean that we
>must
>> get rid of the need to manually plaster PGDLLIMPORT on global
>variables.
>>
>> Anybody with a Windows build environment want to test the "#define
>extern"
>> trick?
>>
>> 			
>
>
>
>We have details on how to build with Mingw/Msys on Windows on an Amazon
>
>VM <http://wiki.postgresql.org/wiki/Building_With_MinGW> which is
>either 
>free or very cheap. Do I need to give instructions on how to do this
>for 
>MSVC builds too? It's really not terribly hard.

Err. It might not be very hard but it certainly is time consuming. And that for people not caring about windows.

If there were usable, regularly refreshed, instances out there'd it'd be slightly less bad. But this still by far the most annoying and intrusive platform to care about.

Andres


-- 
Please excuse brevity and formatting - I am writing this on my mobile phone.

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