winnie 9.4 PostGIS 2.2.or 2.1 build doesn't load in EDB 9.4 beta 32-bit

[robe]

This is only an issue it appears for the mingw32-w64 4.8.0 rev 2 I am using to build the windows 32-bit PostGIS against PostgreSQL 9.4 beta 1. and when you try to create extension postgis in 9.4beta1 32-bit on EDB you get

ERROR: could not load library
The specified procedure could not be found

The builds I tried on winnie and also the one I tried building locally on my windows 7 64-bit don't load in PostgreSQL 9.4beta1 for windows 32-bit EDB (work under mingw). The 64-bit ones work fine.

At first I thought maybe its because the new EDB are built with VC 2013 where as older I think was VC 2012 or 2010.

Now I think it might be something introduced in PostgreSQL 9.4 beta1 that mingw is attaching too since I don't see this function exposed when I look at dependency profile of my 9.3 w32.

Looking at dependency walker, it seems the PostGIS 2.2 dll for 9.4 win 32 is looking for function

The error in dependency walker is:

Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module

and

InterlockedCompareExchange@12 in Postgres.exe is in red

[robe]

Yap I think something changed in how they are handling Interlocking.

Just to simplify things a bit, I tried building pg_trgm extension and while my mingw32 can use the extensions provided by the PostgreSQL 9.4beta1 build EDB windows 32 build the pg_trgm I built (under mingw64-w32) and tried to sneak in to my PostgreSQL 9.4 vc build complains about the same non-existent function.

I'm suspecting something different changed in 9.4 in the ​http://doxygen.postgresql.org/s__lock_8h_source.html

src\include\storage\s_lock.h

since that is where I see reference to _InterlockedExchange and lots of conditions depending on 32-bit/64-bit/intel etc.

As much as I hate to say so. We may need to revisit cmake sooner than later otherwise I may not be able to build for 9.4 windows 32-bit.

[dustymugs]

Your error isn't with _InterlockedExchange as that pertains to IA64. The problem has something to do with InterlockedCompareExchange, which doesn't look like it's changed in PostgreSQL for 9.4

[robe]

Put in a note on pgsql-hackers to find out more.

​http://www.postgresql.org/message-id/E18E764B5E204E7488342C3EEFA0F8EF@O

[robe]

oh boy did they change a lot in the configure scripts and windows scripts.

It's surprising I can compile at all with my 4.8.0w32 chain.

I tried using mingw64-w32 4.8.1 rev2 (4.8.2, and 4.8.3) but those couldn't even get passed the configure step — got a on 4.8.1

undefined reference to `_set_invalid_parameter_handler'

Just to make sure it wasn't my 4.8.1 chain, I tried compiling 9.3.4 with that got past configure and is on its compile way.

pramsey if you still have your mingw32 4.8.1 chain, can you see if you can compile 9.4beta1 with it to rule out something on my windows 7 64-bit conflicting.

[robe]

4.8.1w32 was able to compile 9.3.4 fine but still no luck with the latest 9.4 snapshot from ​ftp://ftp.postgresql.org/pub/snapshot/dev/

[robe]

switching this to 2.1. Since we aren't going to make the 9.4 cut, this has to be fixed for 2.1 as well. though I think the issue is with PostgreSQL 9.4, so probably nothing needs to change in our code base.

[robe]

Success I think. So far upgrading to new 4.8.1 chain and change the templates/win32 file to

LDFLAGS="-Wl,--allow-multiple-definition -Wl,--disable-auto-import"

to

LDFLAGS="-Wl,--allow-multiple-definition"

Seems to have fixed the problem with configure on mingw64-w32 gcc 4.8.1 and above (I tried from 4.8.1-4.9.0)

and better yet — it doesn't have the annoying

 InterlockedCompareExchange

reference. As an experiment I tried to load my pg_trgm compiled 4.8.1 extension into my edb 9.4beta install, and that seems to have worked fine. So worst comes to worst, I guess I got to upgrade my chain to 4.8.1 or above and we may not have to rush into CMake just yet.

[robe]

related bug for gcc 4.8.1+ I posted at:

​http://www.postgresql.org/message-id/99EEB0452E144CFEAA650076F2C8431D@O

[robe]

Looking good so far. All tests pass against my EDB 32-bit 9.4beta 1 — ain't that a beaut site:

PostgreSQL 9.4beta1, compiled by Visual C++ build 1800, 32-bit
  Postgis 2.2.0dev
 - r12585
 - 2014-05-26 03:53:17
  scripts 2.2.0dev r12585
  raster scripts 2.2.0dev r12585
  GEOS: 3.5.0dev-CAPI-1.9.0 r3985
  PROJ: Rel. 4.8.0, 6 March 2012
  GDAL: GDAL 1.11.0, released 2014/04/16

Postgres devs are still deciding what do to about this: ​http://www.postgresql.org/message-id/12441.1401043380@sss.pgh.pa.us

I'm uncomfortable about the fact that my gcc 4.8.0 compiled but had that extra load function reference making it inoperable, and replacing that win32 template file seemed to not fix the issue or perhaps it did and I missed something.

I'm even more puzzled that upgrading to gcc 4.8.1 made configure not work at all but changing the template/win32 file back to

LDFLAGS="-Wl,--allow-multiple-definition"

fixed both problems. I'll look the gift horse in the mouth later.

So far I've built 2.2 (and whole new set of libraries GDAL 1.11.0, GEOS 3.5.0dev, etc. with my new chain). For some reason couldn't build libxml2 so using my gcc 4.8.0 built one for compiling. I never distribute the mingw libxml anyway.