[raster] GDALPolygonize not being set to 1 when compiling with GDAL 1.9

[robe]

I suspect this is just mingw issue.

Getting back to what was discussed in: ​http://www.postgis.org/pipermail/postgis-devel/2011-December/016389.html

— my raster_config.h has settings like below after configure

/* GDAL library version */
#define POSTGIS_GDAL_VERSION 19

/* Define to 1 if GDAL has GDALFPolygonize function. */
#define GDALFPOLYGONIZE 0

Note it does register my 1.9 (GDAL trunk but is not giving me the new GDALFPOLYGONIZE behavior) so I assume something is wrong with our check logic as committed in r7316 or I'm doing something wrong in my GDAL compile.

If I manually override after configure

#define GDALFPOLYGONIZE 1

and then compile make check. All tests pass. Do our raster regress tests do any conditional checks if GDALFPOLYGONIZE is enabled similar to what our regular postgis tests (if you are running GEOS 3.3+)? Unfortunately I don't have any rasters lying around that are float to test with.

[Bborie Park]

Our raster regression tests (particularly test/core/testapi.c) have conditional checks for GDALFPOLYGONIZE. Since the regressions passed with you manually setting GDALFPOLYGONIZE, the only place for the issue is the configure step. Can you attach your config.log to this ticket?

I'll attach a 32BF raster for your testing.

[Bborie Park]

sample 32BF raster. specifically, temperature max for 2010-08-30 in CA.

[robe]

bborie,

Haven't had a chance to test the file. would testing with dump as polygons work?

I'm attaching my config log for my 9.1 install.

[Bborie Park]

Yes. If you create a raster with floating point values (like 3.14159) and use ST_DumpAsPolygons, that would quickly test it. I'll take a look at your config.log shortly…

[robe]

Okay I see numbers like 17.4885787963867 with your sample raster

so I guess its okay

[Bborie Park]

So the problem is in the configure step. Interesting…

[Bborie Park]

Regina, can you upload the config.log file instead? The configure91.log doesn't show the gore that happens when configure runs.

[robe]

I think this one might be for 8.4 since that's probably the last I compiled should be teh same though

[robe]

okay I've attached — that one is probably for 8.4 but it has the same issue.

[Bborie Park]

Just the important bits.

configure:18421: checking for GDALFPolygonize in -lgdal
configure:18446: gcc -o conftest.exe -g -O2  -I/c/projects/geos/rel-3.3.2SVN/include -I/c/projects/proj/rel-4.6.1/include -I/c/projects/json-c/rel-0.9/include -I/c/projects/libxml/libxml2-2.7.8release/include/libxml2  conftest.c -lgdal  -lxml2 -L/c/projects/libxml/libxml2-2.7.8release/lib -lxml2 -liconv -lws2_32 >&5
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lgdal
collect2: ld returned 1 exit status

So it looks like the linker can't find GDAL. I wonder if if specifying -L/c/projects/GDAL/rel-trunk/lib would help that (kinda like for xml2).

[Bborie Park]

I'm guessing you either need to set the env variable LDFLAGS such as in…

LDFLAGS="-L/c/projects/GDAL/rel-trunk/lib" ./configure ...

or have mingw's ld search path set. In linux, the search paths can be set in /etc/ld.so.conf and run ldconfig afterwards.

[robe]

Bborie,

Thanks — setting the LDFLAGS environment variable seems to do the trick.