Can't compile under Windows mingw

[robe]

strk,

You aksed — just tried compiling latest r7741 and can't. I was able to compile and make check fine about 2 days ago.

gcc -g -O2 -Ic:/projects/pg/pg84/include/POSTGR~1/server -I/c/projects/proj/rel-4.6.1/include -I../liblwgeom  -DDLL_EXPORT -DPIC  -Wall -Wmissing-prototypes  -c -o lwgeom_transform.o lwgeom_transform.c
In file included from c:/projects/pg/pg84/include/POSTGR~1/server/c.h:854,
                 from c:/projects/pg/pg84/include/POSTGR~1/server/postgres.h:47,
                 from lwgeom_transform.c:13:
c:/projects/pg/pg84/include/POSTGR~1/server/port.h:17:19: netdb.h: No such file or directory

does same with my 9.0. Didn't bother trying 9.1.

Let me know if you need full log.

[robe]

To answer your question before you ask it.

If I:

cd liblwgeom make make check

That works compiles and make check passes. So I presume must be another ordering issue

[strk]

Your error seems to be in libpgcommon, not liblwgeom. That directory is _not_ using PGXS, maybe it should.

[strk]

Adding bnordgren in Cc, being the author of the initial patch for libpgcommon

[strk]

For reference, #1053 is the ticket about the new libpgcommon directory.

[strk]

Regina, libpgcommon is actually using PGSQL_BE_CPPFLAGS, so _should_ be finding everything needed for postgresql… where's your netdb.h ? I have one in /usr/include and a few under postgresql-xxx/include/server/port/win32. I suspect PGXS would take care of adding -I…/port for win32

[strk]

Regina, to confirm: cd libpgcommon && make

[robe]

strk,

cd libpgcommon && make

fails. Log looks like this:

gcc -g -O2 -I/c/projects/proj/rel-4.6.1/include -Ic:/projects/pg/pg84/include/POSTGR~1/server -I../liblwgeom  -DDLL_EXPORT -DPIC  -Wall -Wmissing-prototypes  -c -o lwgeom_transform.o lwgeom_transform.c
In file included from c:/projects/pg/pg84/include/POSTGR~1/server/c.h:854,
                 from c:/projects/pg/pg84/include/POSTGR~1/server/postgres.h:47,
                 from lwgeom_transform.c:13:
c:/projects/pg/pg84/include/POSTGR~1/server/port.h:17:19: netdb.h: No such file or directory
c:/projects/pg/pg84/include/POSTGR~1/server/port.h:18:17: pwd.h: No such file or directory
c:/projects/pg/pg84/include/POSTGR~1/server/port.h:372:24: netinet/in.h: No such file or directory
c:/projects/pg/pg84/include/POSTGR~1/server/port.h:373:23: arpa/inet.h: No such file or directory
In file included from c:/projects/pg/pg84/include/POSTGR~1/server/postgres.h:48,
                 from lwgeom_transform.c:13:
c:/projects/pg/pg84/include/POSTGR~1/server/utils/elog.h:41:1: warning: "ERROR" redefined
In file included from C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:52,
                 from c:/projects/pg/pg84/include/POSTGR~1/server/pg_config_os.h:21,
                 from c:/projects/pg/pg84/include/POSTGR~1/server/c.h:87,
                 from c:/projects/pg/pg84/include/POSTGR~1/server/postgres.h:47,
                 from lwgeom_transform.c:13:
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/wingdi.h:313:1: warning: this is the location of the previous definition
make: *** [lwgeom_transform.o] Error 1

[robe]

I do have a netdb.h and its in —

C:\projects\pg\pg84\include\postgresql\server\port\win32\netdb.h

That's the only one I see though. Don'ts ee one in my msys or mingw folders

[bnordgren]

Replying to strk:

Regina, libpgcommon is actually using PGSQL_BE_CPPFLAGS, so _should_ be finding everything needed for postgresql… where's your netdb.h ? I have one in /usr/include and a few under postgresql-xxx/include/server/port/win32. I suspect PGXS would take care of adding -I…/port for win32

I added PGSQL_BE_CPPFLAGS myself, as the result of $PGCONFIG --includedir-server so if we figure out what else needs to be added for Windows, this is the place to put it. Is the netdb.h file in any of the directories which can be mined from pg_config?

I'm not using PGXS because, as I read it, it makes *.so files and complete postgresql extension modules. libpgcommon needs to be static.

[bnordgren]

Since win32 seems to be a special case, I just manually added the include directory iff the host is a mingw32. (e.g., it shouldn't clobber the system netdb.h if compiling on linux) See if this fixes it:

​https://github.com/bnordgren/postgis/commit/479c1c67614d2055c84f536df9cdf0f2820eed2f

You'll have to re-run autogen.sh and configure.

[robe]

Sadly did not work after autogen.sh configure. Still same problem.

gcc -g -O2 -Ic:/projects/pg/pg84/include/POSTGR~1/server -I/c/projects/proj/rel-4.6.1/include -I../liblwgeom  -DDLL_EXPORT -DPIC  -Wall -Wmissing-prototypes  -c -o lwgeom_transform.o lwgeom_transform.c
In file included from c:/projects/pg/pg84/include/POSTGR~1/server/c.h:854,
                 from c:/projects/pg/pg84/include/POSTGR~1/server/postgres.h:47,
                 from lwgeom_transform.c:13:
c:/projects/pg/pg84/include/POSTGR~1/server/port.h:17:19: netdb.h: No such file or directory
c:/projects/pg/pg84/include/POSTGR~1/server/port.h:18:17: pwd.h: No such file or directory
c:/projects/pg/pg84/include/POSTGR~1/server/port.h:372:24: netinet/in.h: No such file or directory
c:/projects/pg/pg84/include/POSTGR~1/server/port.h:373:23: arpa/inet.h: No such file or directory
In file included from c:/projects/pg/pg84/include/POSTGR~1/server/postgres.h:48,
                 from lwgeom_transform.c:13:
c:/projects/pg/pg84/include/POSTGR~1/server/utils/elog.h:41:1: warning: "ERROR" redefined
In file included from C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:52,
                 from c:/projects/pg/pg84/include/POSTGR~1/server/pg_config_os.h:21,
                 from c:/projects/pg/pg84/include/POSTGR~1/server/c.h:87,
                 from c:/projects/pg/pg84/include/POSTGR~1/server/postgres.h:47,
                 from lwgeom_transform.c:13:
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/wingdi.h:313:1: warning: this is the location of the previous definition
make: *** [lwgeom_transform.o] Error 1

[bnordgren]

Replying to robe:

Sadly did not work after autogen.sh configure. Still same problem.

Just to confirm, you did manually edit configure.ac to apply the patch in the above github link, correct? (…prior to the autogen.sh and configure)

If so, I'm not sure I understand why the extra directory was not picked up. We may need to grab someone with more experience with autoconf, as I am limited to copying and pasting promising looking snippets.

[strk]

You need AC_CANONICAL_HOST for $host to be defined. Try adding an 'echo "——-"$host' line to see what you get.

[strk]

Forget it, we already print ${host} by the end of configure:

PostGIS is now configured for ${host}

What does it say there, robe ?

[robe]

i686-pc-mingw32

[strk]

Please try r7748 (quoting was missing in Bryce's patch)

[robe]

I think its better, but now I get different errors:

geometry_gist_selectivity.c:1507:28: warning: no newline at end of file
dlltool --export-all  --output-def libpostgis-2.0dll.def lwgeom_debug.o lwgeom_accum.o lwgeom_spheroid.o lwgeom_ogc.o lwgeom_functions_analytic.o lwgeom_inout.o lwgeom_estimate.o lwgeom_functions_basic.o lwgeom_gist.o lwgeom_btree.o lwgeom_box.o lwgeom_box3d.o lwgeom_box2dfloat4.o lwgeom_geos.o lwgeom_geos_prepared.o lwgeom_geos_clean.o lwgeom_geos_relatematch.o lwgeom_export.o lwgeom_in_gml.o lwgeom_in_kml.o lwgeom_triggers.o lwgeom_dump.o lwgeom_functions_lrs.o long_xact.o lwgeom_sqlmm.o lwgeom_rtree.o geography_inout.o gserialized_gist.o gserialized_typmod.o gserialized_gist_2d.o gserialized_gist_nd.o geography_btree.o geography_estimate.o geography_measurement.o geometry_gist_selectivity.o
dllwrap  -o postgis-2.0.dll --dllname postgis-2.0.dll  --def libpostgis-2.0dll.def lwgeom_debug.o lwgeom_accum.o lwgeom_spheroid.o lwgeom_ogc.o lwgeom_functions_analytic.o lwgeom_inout.o lwgeom_estimate.o lwgeom_functions_basic.o lwgeom_gist.o lwgeom_btree.o lwgeom_box.o lwgeom_box3d.o lwgeom_box2dfloat4.o lwgeom_geos.o lwgeom_geos_prepared.o lwgeom_geos_clean.o lwgeom_geos_relatematch.o lwgeom_export.o lwgeom_in_gml.o lwgeom_in_kml.o lwgeom_triggers.o lwgeom_dump.o lwgeom_functions_lrs.o long_xact.o lwgeom_sqlmm.o lwgeom_rtree.o geography_inout.o gserialized_gist.o gserialized_typmod.o gserialized_gist_2d.o gserialized_gist_nd.o geography_btree.o geography_estimate.o geography_measurement.o geometry_gist_selectivity.o  -Lc:/projects/pg/pg84/lib -lpostgres -L/c/projects/geos/rel-3.3.1SVN/lib -L/c/projects/proj/rel-4.6.1/lib -L/c/projects/libxml/libxml2-2.7.8release/lib -Lc:/projects/pg/pg84/lib ../libpgcommon/libpgcommon.a ../liblwgeom/.libs/liblwgeom.a -lgeos_c -lproj -lxml2 -liconv -lws2_32 
../libpgcommon/libpgcommon.a(lwgeom_pg.o): In function `pg_alloc':
c:/projects/PostGIS/trunk/libpgcommon/lwgeom_pg.c:128: undefined reference to `errmsg_internal'
../libpgcommon/libpgcommon.a(lwgeom_pg.o): In function `pg_error':
c:/projects/PostGIS/trunk/libpgcommon/lwgeom_pg.c:161: undefined reference to `pg_vsnprintf'
c:/projects/PostGIS/trunk/libpgcommon/lwgeom_pg.c:164: undefined reference to `errmsg_internal'
../libpgcommon/libpgcommon.a(lwgeom_pg.o): In function `pg_notice':
c:/projects/PostGIS/trunk/libpgcommon/lwgeom_pg.c:181: undefined reference to `errmsg_internal'
../libpgcommon/libpgcommon.a(lwgeom_transform.o): In function `DeleteFromPROJ4SRSCache':
c:/projects/PostGIS/trunk/libpgcommon/lwgeom_transform.c:580: undefined reference to `MemoryContextDelete'
../libpgcommon/libpgcommon.a(lwgeom_transform.o): In function `SetPROJ4LibPath':
c:/projects/PostGIS/trunk/libpgcommon/lwgeom_transform.c:616: undefined reference to `_imp__my_exec_path'
c:/projects/PostGIS/trunk/libpgcommon/lwgeom_transform.c:616: undefined reference to `get_share_path'
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

full log attached:

[robe]

errors after mingw configure patch

[robe]

Actually my 9.0 and 9.1beta3 got a bit further and compiles to postgis-2.0.dll but fails when building the raster dll.

gcc -g -O2  -DDLL_EXPORT -DPIC  -Wall -Wmissing-prototypes -Ic:/projects/PostGIS/trunk/liblwgeom -I/c/projects/GDAL/rel-trunk/include   -c -o rt_api.o rt_api.c
In file included from rt_api.h:90,
                 from rt_api.c:39:
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:22:22: proj_api.h: No such file or directory
In file included from rt_api.h:90,
                 from rt_api.c:39:
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2200: error: syntax error before "lwproj_from_string"
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2200: warning: type defaults to 

I had an extra include of proj for my 8.4 build that I put in during debug that I thought may have been causing the problem, but getting rid of that didn't help.

[robe]

Sadly my postgis.dll built doesn't on my 9.0 doesn't work and fails on regress with this:

BEGIN
psql:c:/projects/PostGIS/trunk/regress/postgis.sql:63: ERROR:  incompatible library "c:/projects/PostGIS/trunk/regress/00-regress-install/lib/postgis-2.0.dll": missing magic block
HINT:  Extension libraries are required to use the PG_MODULE_MAGIC macro.

[strk]

Please try r7749 for the problem with 9.x and raster. As for the other, it seems to be again a problem of library order, but I'm not sure how to fix as the ordering seems to be driven by PGXS itself. Let me know if we're good with 9.0 and 9.1 first…

[strk]

@robe, to test if library order _is_ the problem with your 8.4, you could try running manually these, under the postgis/ directory:

Failing one (original call):

dllwrap  -o postgis-2.0.dll --dllname postgis-2.0.dll  --def libpostgis-2.0dll.def lwgeom_debug.o lwgeom_accum.o lwgeom_spheroid.o lwgeom_ogc.o lwgeom_functions_analytic.o lwgeom_inout.o lwgeom_estimate.o lwgeom_functions_basic.o lwgeom_gist.o lwgeom_btree.o lwgeom_box.o lwgeom_box3d.o lwgeom_box2dfloat4.o lwgeom_geos.o lwgeom_geos_prepared.o lwgeom_geos_clean.o lwgeom_geos_relatematch.o lwgeom_export.o lwgeom_in_gml.o lwgeom_in_kml.o lwgeom_triggers.o lwgeom_dump.o lwgeom_functions_lrs.o long_xact.o lwgeom_sqlmm.o lwgeom_rtree.o geography_inout.o gserialized_gist.o gserialized_typmod.o gserialized_gist_2d.o gserialized_gist_nd.o geography_btree.o geography_estimate.o geography_measurement.o geometry_gist_selectivity.o  -Lc:/projects/pg/pg84/lib -lpostgres -L/c/projects/geos/rel-3.3.1SVN/lib -L/c/projects/proj/rel-4.6.1/lib -L/c/projects/libxml/libxml2-2.7.8release/lib -Lc:/projects/pg/pg84/lib ../libpgcommon/libpgcommon.a ../liblwgeom/.libs/liblwgeom.a -lgeos_c -lproj -lxml2 -liconv -lws2_32 

Hopefully working one:

dllwrap  -o postgis-2.0.dll --dllname postgis-2.0.dll  --def libpostgis-2.0dll.def lwgeom_debug.o lwgeom_accum.o lwgeom_spheroid.o lwgeom_ogc.o lwgeom_functions_analytic.o lwgeom_inout.o lwgeom_estimate.o lwgeom_functions_basic.o lwgeom_gist.o lwgeom_btree.o lwgeom_box.o lwgeom_box3d.o lwgeom_box2dfloat4.o lwgeom_geos.o lwgeom_geos_prepared.o lwgeom_geos_clean.o lwgeom_geos_relatematch.o lwgeom_export.o lwgeom_in_gml.o lwgeom_in_kml.o lwgeom_triggers.o lwgeom_dump.o lwgeom_functions_lrs.o long_xact.o lwgeom_sqlmm.o lwgeom_rtree.o geography_inout.o gserialized_gist.o gserialized_typmod.o gserialized_gist_2d.o gserialized_gist_nd.o geography_btree.o geography_estimate.o geography_measurement.o geometry_gist_selectivity.o  ../libpgcommon/libpgcommon.a ../liblwgeom/.libs/liblwgeom.a -Lc:/projects/pg/pg84/lib -lpostgres -L/c/projects/geos/rel-3.3.1SVN/lib -L/c/projects/proj/rel-4.6.1/lib -L/c/projects/libxml/libxml2-2.7.8release/lib -Lc:/projects/pg/pg84/lib -lgeos_c -lproj -lxml2 -liconv -lws2_32 

[robe]

strk with r7757 that fixes my ability to compile to a raster dll for my 9.0. However I still have the more pressing problem that the dll it generates is not useable.

regress log still shows same thing:

SET
BEGIN
psql:c:/projects/PostGIS/trunk/regress/postgis.sql:63: ERROR:  incompatible library "c:/projects/PostGIS/trunk/regress/00-regress-install/lib/postgis-2.0.dll": missing magic block
HINT:  Extension libraries are required to use the PG_MODULE_MAGIC macro.

I'm chekcing on my 8.4 now.

[robe]

Okay for 8.4 that hack makes it compile to .dll. make check gives me a can't find libgeos_c.dll but sure that's probably easy enough to fix. Haven't tried to see if I have the same issue with loading into PostgreSQL as I do with 9.0

[robe]

I confirmed my 8.4 postgis.dll is also no good — get same error when I go to install in a fresh db

ERROR:  incompatible library "C:/projects/postgis/pg/pg84/lib/postgis-2.0.dll": missing magic block
HINT:  Extension libraries are required to use the PG_MODULE_MAGIC macro.

[strk]

PG_MODULE_MAGIC macro is in libpgcommon/lwgeom_pg.c, wrapped in an ifdef. Could you try commenting out the #ifdef/#endif parts maybe ? Or could again be an ordering problem.

[bnordgren]

Replying to strk:

PG_MODULE_MAGIC macro is in libpgcommon/lwgeom_pg.c, wrapped in an ifdef. Could you try commenting out the #ifdef/#endif parts maybe ? Or could again be an ordering problem.

This is the same code as it existed pre-move (source:/trunk/postgis/lwgeom_pg.c@7733​). Prior to the formation of libpgcommon, both postgis and raster included this code separately. After making libpgcommon, I was having problems with raster-2.0.so due to a duplicate symbol definition (once in libpgcommon and once in raster.) I elected to remove the definition from rt_pg.c in favor of the common location. postgis-2.0.so was fine because it included the symbol only once. And all rejoiced, having passed the regression tests.

If I understand the problem correctly, linux copies this symbol when linking from postgis-2.0.so to libpgcommon.a, but Windows dllwrap filters it out (perhaps because it is never referenced). If we cannot find a way to please all linkers, I would suggest moving this code snippet back into rt_pg.c and one *.c file of your choice in the postgis directory.

[robe]

strk,

Removing the ifdef stuff didn't help. I think Bryce is probably right — we might have to put the links back in raster and postgis separately.

I'll give that a try next and see if that fixes things. Anyrate that if def should be removed since we don't support anything lower than 8.4 on 2.0 anyway and last time we support 8.2 I think was in 1.4

[robe]

Well I think I made some progress. I added PG_MODULE_MAGIC to postgis/lwgeom_geos.c

right before the datum stuff (Line 23).

And got this far:

whole bunch of create function stuff successful and then
breaks in
psql:c:/projects/PostGIS/trunk/regress/postgis.sql:2175: ERROR:  could not find function "transform_geom" in file "c:/projects/PostGIS/trunk/regress/00-regress-install/lib/postgis-2.0.dll"

[strk]

Can it be you need some explicit DLLEXPORT kind of switch for symbols meant to be used outside of the libpgcommon.a file ?

[bnordgren]

Something is mighty hoakey. I started having similar problems when preparing the patch for #1161. As it turns out, whenever I moved a function to libpgcommon which needed to be exposed to sql, I started to have problems with the regression. I settled on moving only the C functions, and not things like:

PG_FUNCTION_INFO_V1(transform_geom);
Datum transform_geom(PG_FUNCTION_ARGS)
{
...
}

The hoakey part is that transform_geom has been moved to libpgcommon in my build too, and the regressions pass just fine. Same platform, same concept (moving a V1 PG_FUNCTION to libpgcommon from postgis), two different results. This seems to be a very strange linker issue. Perhaps it would be wiser to keep all the V1 PG functions in /postgis or /raster, and factor out only the C code.

Besides, we really don't want to expose transform_geom to SQL from both the postgis and raster modules, I don't think…

[robe]

I thought maybe it was none of the functions in libpgcommon were being picked up, but it seems its just the ones in lwgeom_transform.c. The lwgeom_pg.c that have DATUMS e.g. lwgeom_pg.h seem to have installed fine since I can use ST_Force_4D etc. from PostgreSQL using this binary.

I did get a notice about proj can't be dynamically linked or something so perhaps that is a signal. I don't recall seeing that notice before this move to libpgcommon, but it is possible I just wasn't paying attention.

*** Warning: This system can not link to static lib archive /c/projects/proj/rel-4.6.1/lib/libproj.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries

I am puzzled though — why does lwgeom_pg.h have the DATUMS for lwgeom_pg.c, but yet lwgeom_transform.c the DATUMS are just thrown in there instead of in the header file. Is there a reason for what seems to me like an inconsistency? I tried moving over the DATUMS to the lwgeom_transform.h and it compiled, but didn't seem to solve my problem.

HINT HINT: Mark C., if you are paying attention — now would be a really good time to express your words of wisdom since you know more about this mingw stuff than any of us.

[robe]

Bryce,

I had tried moving the Datum back to the postgis side, thought trying to remmeber if I also took it out of libpgcommon. As I recalled, it compiled but still gave the same error. I agree though we probably only want to expose on postgis or raster.

[bnordgren]

Replying to robe:

I thought maybe it was none of the functions in libpgcommon were being picked up, but it seems its just the ones in lwgeom_transform.c. The lwgeom_pg.c that have DATUMS e.g. lwgeom_pg.h seem to have installed fine since I can use ST_Force_4D etc. from PostgreSQL using this binary.

The function declarations in lwgeom_pg.h are just declarations. They do not seem to be implemented in lwgeom_pg.c. I think the important part w.r.t. exposing the code to the SQL layer is that PG_FUNCTION_INFO_V1(fn_name); macro. I'd bet those functions are implemented somewhere under the postgis/ directory.

*** Warning: This system can not link to static lib archive /c/projects/proj/rel-4.6.1/lib/libproj.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries

This could well be a problem, but I defer to strk.

I am puzzled though — why does lwgeom_pg.h have the DATUMS for lwgeom_pg.c, but yet lwgeom_transform.c the DATUMS are just thrown in there instead of in the header file. Is there a reason for what seems to me like an inconsistency? I tried moving over the DATUMS to the lwgeom_transform.h and it compiled, but didn't seem to solve my problem.

My intent was to suggest that the implementations be moved over to the postgis directory, as in this commit on github: ​https://github.com/bnordgren/postgis/commit/b657f94874fee490dfdb000bdb8037290624ffc5

There is more work to do, as this code uses the private projection-cache api. I converted it to the public api in this commit: ​https://github.com/bnordgren/postgis/commit/3daa078ff5901befb8ddc373e0c519e4a24ab2a5

This works for me on linux, but it was working for me before, too. It may be worth a shot.

The super irritating thing is that sometime between this afternoon and this evening, raster started having regressions due to the fact that it could not find the symbol "lwgeom_init_allocators". (But it's still working fine for postgis.) For the life of me, I don't know what changed.

[bnordgren]

Replying to bnordgren:

The super irritating thing is that sometime between this afternoon and this evening, raster started having regressions due to the fact that it could not find the symbol "lwgeom_init_allocators". (But it's still working fine for postgis.) For the life of me, I don't know what changed.

… and this morning it's working for me (but I did have to address some system instabilities via fsck.)

[mcayland]

Replying to robe:

HINT HINT: Mark C., if you are paying attention — now would be a really good time to express your words of wisdom since you know more about this mingw stuff than any of us.

Trying to pay attention, although fairly flat-out at the moment :/ I'm afraid I don't really know without trying to build a copy myself. I did have a mingw cross-compiler setup, but that's for the old 3.4.5 version rather than then newer 4.5.0 compiler so it would take some time to get me back up to speed on this I'm afraid

[robe]

Mark,

I'm still using 3.4.5, not 4.5. I couldn't get the newer gccs to compile GEOS so gave up on that a while ago. So your 3.4.5 should actually work fine.

[strk]

Robe: does raster dll load fine ? I see there's an explicit PG_MODULE_MAGIC in rt_pg.c

[robe]

FYI. As of r7766 I was back to things compile but getting MAGIC extension thingymagig required error. (This is compiling my windows 9.0 install — haven't tried the others)

I put in

#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif

In postgis/lwgeom_functions_basic.c and that seemed to fix that issue and postgis make check plpgsql tests passed. Yee pee.

However — my raster is kinda screwed up. It seems to generate the rtpostgis-20.dll, but fails during make check with all sorts of stuff like

cc -g -O2  -DDLL_EXPORT -DPIC  -Wall -Wmissing-prototypes -I../../rt_core -Ic:/projects/PostGIS/trunk/liblwgeom -I/c/projects/GDAL/rel-trunk/include -o testapi testapi.c -lm ../../rt_core/librtcore.a c:/projects/PostGIS/trunk/liblwgeom/.libs/liblwgeom.a -L/c/projects/GDAL/rel-trunk/lib -lgdal 
In file included from ../../rt_core/rt_api.h:90,
                 from testapi.c:7:
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:23:22: proj_api.h: No such file or directory
In file included from ../../rt_core/rt_api.h:90,
                 from testapi.c:7:
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2194: error: syntax error before "lwproj_from_string"
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2194: warning: type defaults to `int' in declaration of `lwproj_from_string'
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2194: warning: data definition has no type or storage class
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2202: error: syntax error before "projPJ"

----------------------------------------------------------------------
Libraries have been installed in:
   /c/projects/pg/pg90/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-LLIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
/bin/sh ../install-sh liblwgeom.h "/liblwgeom.h"
cp: cannot create regular file `//_inst.2160_': No such file or directory
make[1]: *** [install-liblwgeom] Error 1
make[1]: Leaving directory `/c/projects/PostGIS/trunk/liblwgeom'

I'm going to go ahead and try the generated raster to see if they are any good.

[robe]

Okay the rtpostgis-2.0.dll seems to install okay and I could do some simple tests like creating some dummy rasters and reading metadata. So it just seems something is screwed up with the install process.

[strk]

@robe: you mean with or w/out changes ? If with: which changes ? If w/out: which revision ?

[strk]

r7757 contains another big shaking, I'm all ears for mingw experience with it.

[robe]

strk,

Is that the right revision number. That's going backwards no?

For your other question. My 9.0 works with changes (I mean the dlls are good the make check works for postgis), but the install fails with the above. files are both good though postgis and raster .dll. See my attached patch to get to the point I described.

[strk]

Oops, it was r7768. Hopefully will work w/out patches your side (fingers crossed).

[robe]

1 step forward and 1 step back.

I had to get rid of your ifdef 0 (blocking the module magic in rt_pg), for raster not to give the "you need magic" error during load. Still needed the module magic patch for the postgis side. Raster check still fails with

In file included from ../../rt_core/rt_api.h:90,
                 from testapi.c:7:
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:23:22: proj_api.h: No such file or directory
In file included from ../../rt_core/rt_api.h:90,
                 from testapi.c:7:
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2194: error: syntax error before "lwproj_from_string"
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2194: warning: type defaults to `int' in declaration of `lwproj_from_string'
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2194: warning: data definition has no type or storage class
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2202: error: syntax error before "projPJ"
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2203: error: syntax error before "projPJ"
make[3]: *** [testapi] Error 1
make[3]: Leaving directory `/c/projects/PostGIS/trunk/raster/test/core'
make[2]: *** [core-check] Error 2
make[2]: Leaving directory `/c/projects/PostGIS/trunk/raster/test'

though binaries after magic changes work fine.

On the plus side, it does install now. No longer get the "cannot create regular file `_inst.2160_'" error any more.

[strk]

r7772 should fix the proj issue.

[strk]

r7773 does the PG_MODULE_MAGIC move. Are we happy now ?

[robe]

Magic good, postgis tests code, install good, raster test api still no good.

In file included from ../../rt_core/rt_api.h:90,
                 from testapi.c:7:
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2190: error: syntax error before              "lwproj_from_string"
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2190: warning: type defaults to              `int' in declaration of `lwproj_from_string'
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2190: warning: data definition h             as no type or storage class
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2198: error: syntax error before              "projPJ"
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2199: error: syntax error before              "projPJ"
make[3]: *** [testapi] Error 1
make[3]: Leaving directory `/c/projects/PostGIS/trunk/raster/test/core'
make[2]: *** [core-check] Error 2
make[2]: Leaving directory `/c/projects/PostGIS/trunk/raster/test'
make[1]: *** [core-check] Error 2
make[1]: Leaving directory `/c/projects/PostGIS/trunk/raster'
make: *** [check] Error 1
for s in liblwgeom libpgcommon regress postgis loader utils raster topology; do   

I've been getting another error recently which I first saw when trying to apply Bryce's patch and now it shows up all the time during configure.

checking for a BSD-compatible install... m.AllocationBase 0x713D0000, m.BaseAddress 0x715B0000, m.RegionSize 0x38000, m.State 0x1000
C:\msys\1.0\bin\install.exe: *** Couldn't reserve space for cygwin's heap (0x715B0000 <0x2530000>) in child, Win32 error 0
./install-sh -c

The couldn't reserve cygwin space. I'll restart my computer and see if that error goes away and perhaps that will solve the raster test api problem if they are related in someway.

[robe]

Okay restarting fixed my out of reserve space error, but the raster test api problem still exists. If I do this

cd raster/test make

here is the log of what happens:

make -C core check
make[1]: Entering directory `/c/projects/postgis/trunk/raster/test/core'
cc -g -O2  -DDLL_EXPORT -DPIC  -Wall -Wmissing-prototypes -I../../rt_core -Ic:/projects/PostGIS/trunk/liblwgeom -I/c/projects/GDAL/rel-trunk/include -o testapi testapi.c -lm ../../rt_core/librtcore.a c:/projects/PostGIS/trunk/liblwgeom/.libs/liblwgeom.a -L/c/projects/GDAL/rel-trunk/lib -lgdal 
In file included from ../../rt_core/rt_api.h:90,
                 from testapi.c:7:
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:23:22: proj_api.h: No such file or directory
In file included from ../../rt_core/rt_api.h:90,
                 from testapi.c:7:
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2190: error: syntax error before "lwproj_from_string"
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2190: warning: type defaults to `int' in declaration of `lwproj_from_string'
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2190: warning: data definition has no type or storage class
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2198: error: syntax error before "projPJ"
c:/projects/PostGIS/trunk/liblwgeom/liblwgeom.h:2199: error: syntax error before "projPJ"
make[1]: *** [testapi] Error 1
make[1]: Leaving directory `/c/projects/postgis/trunk/raster/test/core'
make: *** [core-check] Error 2

[robe]

Not sure if this helps but if I do this

cd raster
make clean && make

The raster dll and files is built and output looks like this:

make -C rt_core
make[1]: Entering directory `/c/projects/postgis/trunk/raster/rt_core'
gcc -g -O2  -DDLL_EXPORT -DPIC  -Wall -Wmissing-prototypes -Ic:/projects/PostGIS/trunk/liblwgeom -I/c/projects/GDAL/rel-trunk/include -I/c/projects/proj/rel-4.6.1/include   -c -o rt_api.o rt_api.c
ar rs librtcore.a rt_api.o
C:\MinGW\bin\ar.exe: creating librtcore.a
make[1]: Leaving directory `/c/projects/postgis/trunk/raster/rt_core'
make -C rt_pg
make[1]: Entering directory `/c/projects/postgis/trunk/raster/rt_pg'
gcc -E -traditional-cpp rtpostgis.sql.in.c | grep -v '^#' > rtpostgis.sql.in
sed 's,MODULE_PATHNAME,$libdir/rtpostgis-2.0,g' rtpostgis.sql.in >rtpostgis.sql
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv  -I/c/projects/geos/rel-3.3.1SVN/include -I/c/projects/proj/rel-4.6.1/include -I/c/projects/libxml/libxml2-2.7.8release/include/libxml2 -Ic:/projects/PostGIS/trunk/liblwgeom -I/c/projects/GDAL/rel-trunk/include -Ic:/projects/PostGIS/trunk/libpgcommon -I/c/projects/proj/rel-4.6.1/include -I../rt_core -I. -I. -Ic:/projects/pg/pg90/include/POSTGR~1/server -Ic:/projects/pg/pg90/include/POSTGR~1/internal -I./src/include/port/win32 -DEXEC_BACKEND  "-Ic:/projects/pg/pg90/lib/POSTGR~1/pgxs/src/MAKEFI~1/../../src/include/port/win32" -Ic:/projects/pg/pg90/include/POSTGR~1/server/port/win32  -c -o rt_pg.o rt_pg.c
dlltool --export-all  --output-def librtpostgis-2.0dll.def rt_pg.o
dllwrap -o rtpostgis-2.0.dll --dllname rtpostgis-2.0.dll  --def librtpostgis-2.0dll.def rt_pg.o -Lc:/projects/pg/pg90/lib -Wl,--allow-multiple-definition  -Wl,--as-needed   -L/c/projects/geos/rel-3.3.1SVN/lib -L/c/projects/proj/rel-4.6.1/lib -lgeos_c -lproj -L/c/projects/libxml/libxml2-2.7.8release/lib -lxml2 -liconv -lws2_32 ../rt_core/librtcore.a c:/projects/PostGIS/trunk/liblwgeom/.libs/liblwgeom.a c:/projects/PostGIS/trunk/libpgcommon/libpgcommon.a -L/c/projects/GDAL/rel-trunk/lib -lgdal -Lc:/projects/pg/pg90/lib -lpostgres
make[1]: Leaving directory `/c/projects/postgis/trunk/raster/rt_pg'
make -C rt_pg rtpostgis.sql
make[1]: Entering directory `/c/projects/postgis/trunk/raster/rt_pg'
make[1]: `rtpostgis.sql' is up to date.
make[1]: Leaving directory `/c/projects/postgis/trunk/raster/rt_pg'

Looks like the test api one is missing the proj line: -I/c/projects/proj/rel-4.6.1/include

I'll test and see if putting that in fixes it. I presume I have to change the raster/test/core/Makefile.in

[robe]

Okay putting in the similar fix you did for raster fixed the test api issue.

patched at r7774

can people who are setup to compile and test raster verify my change didn't break anything.

I'm going to test on my 8.4 and 9.1 installs and if those pass, then I'll close this ticket out.

Thanks strk

[dustymugs]

All seems to pass on my linux 32 and 64-bit systems as well as an OSX 10.6 64-bit system.

[robe]

Thanks Bborie. I'm still having some issues.

I still can't compile my 8.4. My 9.1beta3 compiles and check builds, but getting many raster check failures on the 9.1 version. I'll post that as a separate ticket under raster since I think it might be pure raster issues or something different about my pg 9.1 configuration paths.

strk — I've attached my 8.4 build log

[strk]

The log shows linker being unable to find symbols in the postgresql library. But I'm not even sure it should look for them (rather than finding them at link time). All I know is that the same symbols were in 1.5 as well, so they were no problem when fully within the PGXS framework.

Mark can probably help with this.

[strk]

Robe, could you please try the attached file:pgcommon_as_object.patch with all your pgsql versions ? The patch only touched postgis module, not raster module, so you may be successfully in postgis and not in raster.

[strk]

That patch is pretty dirty, but would help figuring if it's still an ordering problem. I'm having an hard time to figure out _how_ the link line is built within PGXS. Why did we switch to PGXS again ?

[strk]

It's also interesting to note that on Linux I don't get postgresql library in the link line, while you seem to be getting that (the '-Lc:/projects/pg/pg84/lib -lpostgres' right after objects list). Since that's being the problem I wonder if 9.0 fixed a bug in 8.4 pgxs threatment, and how we can workaround that.

[strk]

Ok, I see the difference between 8.4 and 9.0 now:

8.4: SHLIB_LINK := $(BE_DLLLIBS) $(SHLIB_LINK) 9.0: SHLIB_LINK += $(BE_DLLLIBS)

So, 9.0 works because it _appends_ BE libraries to the link line, while 8.4 prepends them, thus making it impossible to list in SHLIB_LINK our pgsql-dependent libpgcommon.

Now to think of a fix… Back to include our own Makefile.shlib ? (that's where that line comes from)

[strk]

Robe: please try this other patch for a workaround for the 8.4 link line order. The patch is still only for the postgis side of things, but if it works there I'll go on with the raster side.

[robe]

works as long as I don't compile with raster. Can you fix for raster too and then I'll try again.

[robe]

strk, I got impatient waiting for you to save me so I made the same change on raster/rt_pg/Makefile.in myself. Looks good. PostgreSQL 8.4 is now compiling again on windows and all make check passes with flying colors.

My 9.1 still compiles. Still have to retest my 9.0.

Is it okay to commit the changes once I've confirmed all 3 are back to working condition or will that cause a problem for people?

[robe]

strk I've committed your postgis makefile.in change and my parallel rt_pg\makefile.in at r7841.

I'll wait and see if Hudson complains. Feel free to revert if something doesn't work for any of you.