Re: PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load
| От | Tom Lane |
|---|---|
| Тема | Re: PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load |
| Дата | |
| Msg-id | 3673.1400765987@sss.pgh.pa.us обсуждение |
| Ответ на | PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load ("Paragon Corporation" <lr@pcorp.us>) |
| Ответы |
Re: PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load
|
| Список | 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 по дате отправления: