"Paragon Corporation" <l...@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

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

                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to