"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
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
