[GRASS-dev] winGRASS not built/broken

[Markus Metz]

On Sat, Nov 11, 2017 at 6:01 PM, Even Rouault <even.rouault at spatialys.com>
wrote:
>
> On samedi 11 novembre 2017 17:44:18 CET Markus Metz wrote:
>
> > On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky <hellik at web.de>
wrote:
>
> > > it seems there is an issue with winGRASS:
>
> > >
>
> > > 32 bit:
>
> > >
>
> > > https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log
>
> > >
>
> > > GRASS GIS 7.3.svn r71641 compilation log
>
> > > --------------------------------------------------
>
> > > Started compilation: Tue Nov 7 21:30:33 2017
>
> > > --
>
> > > Errors in:
>
> > > /c/msys32/usr/src/grass_trunk/raster/r.in.gdal
>
> >
>
> > The error is:
>
> > main.c:345: undefined reference to `GDALSetCacheMax64 at 4'
>
> >
>
> > strange, GDALSetCacheMax64 should exist on 32 bit Windows, even if "the
>
> > maximum amount of memory that can be addressed by a process might be 2
GB
>
> > or 3 GB, depending on the operating system capabilities."
>
> >
>
> > Falling back to GDALSetCacheMax for MS Windows (including 64 bit
Windows)
>
> > in r71677.
>
>
>
> The issue is probably that this build uses GDAL from OSGeo4W, into which
GDAL has been configured and compiled with MSVC. Thus HAVE_LONG_LONG is not
defined in cpl_config.h, and the GDALSetCacheMax64( GIntBig ) must evaluate
to GDALSetCacheMax64 ( int ) when including from GRASS. I guess defining
HAVE_LONG_LONG would solve the issue .

If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ), we can
just as well use GDALSetCacheMax( int), the argument is the same ( int ).

Markus M
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20171111/127247df/attachment.html>