Обсуждение: PostgreSQL 9.4 InterlockedCompareExchange appearing in mingw64-w32 causing issue with PostGIS win32 load

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)

I'm using mingw64-w32 gcc 4.8.0 rev2.  I have the same chain mingw64-w64 to
build the 64-bit.

The only place I could find reference to this function is in 

src\include\storage\s_lock.h

I have related PostGIS ticket here:

http://trac.osgeo.org/postgis/ticket/2746

Thanks,
Regina Obe

"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

> 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

Tom,

Does it with all extensions, not just PostGIS (before I could swap between
say for example hstore mingw compiled and VC compiled and had no issue).
The Load function as you guessed shows in the extension .dll postgres.exe
reference but not clear where to tell where that is coming thru.  

I'm compiling PostgreSQL the same way in both 9.3 and 9.4:

With something that looks like this:
export MINGHOST=i686-w64-mingw32
PG_VER=9.4

./configure --prefix=${PROJECTS}/postgresql/rel/pg${PG_VER}\ --build=${MINGHOST} \ --with-pgport=8443
--disable-float8-byval--enable-cassert
 
--enable-debug \ --enable-integer-datetimes --without-zlib


With just the PG_VER being different.

What I did notice is that in 9.3, the config.log shows this for 

9.4:
LDFLAGS=-Wl,--allow-multiple-definition -Wl,--disable-auto-import
-Wl,--as-needed


and
9.3:
LDFLAGS=-Wl,--allow-multiple-definition  -Wl,--as-needed

You know what would cause those to change between versions?


I thought maybe the --disable-auto-import was doing something.

I'm trying to override the flag now to see if it makes a difference, but
having difficulty changing what I am seeing in the config.log

When I do any of the below:
export LDFLAGS=-Wl,--allow-multiple-definition -Wl,--enable-auto-import
-Wl,--as-needed
export LDFLAGS="-Wl,--allow-multiple-definition -Wl,--enable-auto-import
-Wl,--as-needed"
export LDFLAGS=-Wl,--allow-multiple-definition  -Wl,--as-needed

Thanks,
Regina

-- REVISED NOTE --
> 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

Tom,

Does it with all extensions, not just PostGIS (before (9.3.4 and before) I
could swap between say for example hstore mingw compiled and VC compiled and
had no issue)
And this extra InterlockedComparedExchange export did not appear in the
extension dlls.
The InterlockedCompareExchange@ export as you guessed shows in the
extension .dll postgres.exe reference but not clear where to tell where that
is coming thru.  

I found this thread which sounds like the situation I am running into, but
not sure why it would be suddenly an issue now unless nothing is being
exported anymore
http://sourceforge.net/p/mingw-w64/mailman/message/31128245/

I'm compiling PostgreSQL the same way in both 9.3 and 9.4:

With something that looks like this:
export MINGHOST=i686-w64-mingw32
PG_VER=9.4

./configure --prefix=${PROJECTS}/postgresql/rel/pg${PG_VER}\ --build=${MINGHOST} \ --with-pgport=8443
--disable-float8-byval--enable-cassert
 
--enable-debug \ --enable-integer-datetimes --without-zlib


With just the PG_VER being different.

What I did notice is that in 9.3, the config.log shows this for 

9.4:
LDFLAGS=-Wl,--allow-multiple-definition -Wl,--disable-auto-import
-Wl,--as-needed


and
9.3:
LDFLAGS=-Wl,--allow-multiple-definition  -Wl,--as-needed

I read thru the threads on mailing list and confirmed it was an intended
change.


I thought maybe the --disable-auto-import was doing something.

Trying to override the flag with

When I do any of the below did not work
export LDFLAGS=-Wl,--allow-multiple-definition -Wl,--enable-auto-import
-Wl,--as-needed
export LDFLAGS="-Wl,--allow-multiple-definition -Wl,--enable-auto-import
-Wl,--as-needed"
export LDFLAGS=-Wl,--allow-multiple-definition  -Wl,--as-needed

However I was able to override it by changing the:
/src/template/win32 (trying both )

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

And the old 9.3.4
LDFLAGS="-Wl,--allow-multiple-definition"


And concluded that was not the issue since the export of this symbol still
happens.

Any other thoughts?

Thanks,
Regina