Can't compile PostGIS 2.0 under mingW

[robe]

strk,

With the latest trunk r7709, I can no longer compile PostGIS 2.0 under MingW.

Attached is full build.log

excerpts that look like the critical area

Info: resolving _xmlFree by linking to __imp__xmlFree (auto-import)
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
../liblwgeom/liblwgeom.a(lwgeom_geos.o): In function `GEOS2LWGEOM':
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:98: undefined reference to `GEOSGetSRID'
../liblwgeom/liblwgeom.a(lwgeom_geos.o): In function `LWGEOM2GEOS':
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:299: undefined reference to `GEOSGeom_createLineString'
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:314: undefined reference to `GEOSGeom_createLinearRing'
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:315: undefined reference to `GEOSGeom_createPolygon'
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:323: undefined reference to `GEOSGeom_createLinearRing'
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:333: undefined reference to `GEOSGeom_createLinearRing'
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:344: undefined reference to `GEOSGeom_createPolygon'
../liblwgeom/liblwgeom.a(lwgeom_geos.o): In function `lwgeom_intersection':
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:457: undefined reference to `GEOSIntersection'
../liblwgeom/liblwgeom.a(lwgeom_geos.o): In function `LWGEOM_GEOS_buildArea':
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:766: undefined reference to `GEOSGetSRID'
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:839: undefined reference to `GEOSCoordSeq_clone'
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:842: undefined reference to `GEOSGeom_createLinearRing'
c:/projects/PostGIS/trunk/liblwgeom/lwgeom_geos.c:842: undefined reference to `GEOSGeom_createPolygon'
collect2: ld returned 1 exit status
C:\MinGW\bin\dllwrap.exe: C:\MinGW\bin\gcc exited with status 1
make[1]: *** [postgis-2.0.dll] Error 1
make[1]: Leaving directory `/c/projects/PostGIS/trunk/postgis'
make: *** [all] Error 1

[strk]

Could you please try r7696 and r7695 ? I suspect it's been introduced by r7696.

[robe]

I know r7695 works since that was my commit and I was able to compile then. I'll try r7696.

[robe]

r7696 doesn't work either but gives slightly different errors. See attached for full details.

some snippets from it. Seems to have more errors

lwgeom_geos.h:5:20: geos_c.h: No such file or directory
In file included from lwgeom_geos.c:1:
lwgeom_geos.h:21: warning: type defaults to `int' in declaration of `GEOSGeometry'
lwgeom_geos.h:21: error: syntax error before '*' token
lwgeom_geos.h:22: error: syntax error before '*' token
lwgeom_geos.h:22: warning: type defaults to `int' in declaration of `LWGEOM2GEOS'
lwgeom_geos.h:22: warning: data definition has no type or storage class
lwgeom_geos.h:24: warning: type defaults to `int' in declaration of `GEOSCoordSequence'
lwgeom_geos.h:24: error: syntax error before '*' token
lwgeom_geos.c:35: warning: type defaults to `int' in declaration of `GEOSCoordSequence'
lwgeom_geos.c:35: error: syntax error before '*' token
lwgeom_geos.c:36: warning: no previous prototype for 'ptarray_from_GEOSCoordSeq'
lwgeom_geos.c: In function `ptarray_from_GEOSCoordSeq':

[strk]

Ok, back to r7709, does 'make && make check' work under liblwgeom only ?

[robe]

Yap that works and creates liblwgeom.a and all CUnit tests pass.

[robe]

shouldn't it be building a .dll file though? Thought postgis*.dll is supposed to dynamically link to it. I only see a .a being built.

[bnordgren]

If my picture on #1133 does not deviate too far from reality, liblwgeom is static, while "postgis users" such as postgis and raster are dynamic.

[bnordgren]

Looking at your build log (for r7709) closer, this is even more peculiar than at first blush. An item in liblwgeom can't find another item in the same library? Really?

This smacks of issues I used to have with the ordering of object files and libraries on the command line. Two things I can think of to try:

On the following command line (probably in the Makefile.in in the liblwgeom directory), move lwgeom_geos.o just before stringbuffer.o. If memory serves, you just have to move it to the front of the OBJS variable in the Makefile.in:

ar rs liblwgeom.a stringbuffer.o measures.o measures3d.o box2d.o ptarray.o lwgeom_api.o lwgeom.o lwpoint.o lwline.o lwpoly.o lwtriangle.o lwmpoint.o lwmline.o lwmpoly.o lwcollection.o lwcircstring.o lwcompound.o lwcurvepoly.o lwmcurve.o lwmsurface.o lwpsurface.o lwtin.o lwout_wkb.o lwin_wkb.o lwout_wkt.o lwin_wkt_parse.o lwin_wkt_lex.o lwin_wkt.o lwutil.o lwhomogenize.o lwalgorithm.o lwgunparse.o lwgparse.o lwsegmentize.o lwprint.o wktparse.tab.o lex.yy.o vsprintf.o g_box.o g_serialized.o g_util.o lwgeodetic.o lwtree.o libtgeom.o lwout_gml.o lwout_kml.o lwout_geojson.o lwout_svg.o lwout_x3d.o lwgeom_geos.o lwspheroid.o

Another thing to try is to "refresh" the index after the library has been built. (e.g., after running 'make && make check' in liblwgeom, run ranlib liblwgeom.a, then continue with the full build.)

What version of binutils and gcc is bundled with your MingW installation?

[strk]

The undefined symbols come from libgeos (external). Try the attached patch, lists the static liblwgeom _before_ the dynamic libgeos...

[strk]

apply with patch -p1

[strk]

@robe : a shared liblwgeom is not being built by default yet, as all our users are linking against the static library instead. If you want to try generation of the dynamic library you have to explicitly run 'make -C liblwgeom/ liblwgeom.so', but that target is a moving one (we may get back to libtool)

[bnordgren]

Replying to strk:

The undefined symbols come from libgeos (external).

I just realized that myself.

Try the attached patch, lists the static liblwgeom _before_ the dynamic libgeos...

+1 Seems the most likely culprit given the missing symbols are in libgeos.

[robe]

strk that patch works for me. I've gone ahead and committed it at r7710.

Thanks, Regina

[mcayland]

Correct. Just for the record, linking under Windows is order-sensitive (resolution from left to right) due to the way in which Windows resolves symbols within library files so this should be the correct fix.