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 по дате отправления: