Re: PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load
Date
Msg-id 3673.1400765987@sss.pgh.pa.us
Whole thread Raw
In response to PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load  ("Paragon Corporation" <lr@pcorp.us>)
Responses Re: PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load
List pgsql-hackers
"Paragon Corporation" <lr@pcorp.us> writes:
> Not sure if people know this, but PostGIS windows builds are built with
> mingw64-w32 and mingw64-w64 chains and usually used with EDB VC++ built
> PostgreSQL. 
> This is mostly because there is too much unix stuff ingrained in PostGIS
> toolchain making it difficult to compile in VC++.

> Anyrate this has worked fine in the past, but when I tried the mingw64-w32
> build in the EDB PostgreSQL 9.4beta1 Windows 32, it failed to load.

> The 64-bit chain still works fine and regresses fine against PostGIS tests.

> I looked at dependency walker, and noticed what was additional in the mingw
> postgres that couldn't be found in the 9.4beta1 EDB postgres was a function:

> InterlockedCompareExchange@12

> I'm pretty sure this must be something that has changed in 9.4 because I'm
> using the same chain to build 9.3 for 32-bit and this 
> InterlockedCompareExchange call doesn't exist in 9.3 (niether the ming
> compiled or edb compiled)

Hm.  s_lock.h does define TAS() in terms of InterlockedCompareExchange()
if WIN32_ONLY_COMPILER is defined ... but that code hasn't changed in
quite a long time.  It seems like the combination of an extension built
with WIN32_ONLY_COMPILER and a core built without that flag should never
have worked, if the core is what has to link in
InterlockedCompareExchange.

I wonder if there is something you're doing that results in inlining
a spinlock call given the 9.4 headers, but did not previously.  Can
you narrow down what part of your code is giving rise to the undefined
reference?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 9.5 commit fest schedule
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3