[gdal-dev] direct.h and other Windows issue

[Even Rouault]

Le jeudi 10 décembre 2015 10:11:19, Martin Landa a écrit :
> Hi all,
> 
> currently I am working on Windows GRASS builds (using MSYS2 +
> MinGW64). I have still some issue with GDAL which I am not sure how to
> correctly solve:
> 
> 1) GDAL has enabled in cpl_port.h
> 
> #ifdef HAVE_DIRECT_H
> #  include <direct.h>
> #endif
> 
> which is old header used by MSVC, modern is dirent.h, right?

https://en.wikipedia.org/wiki/Direct.h
http://pubs.opengroup.org/onlinepubs/7908799/xsh/dirent.h.html

Don't seem quite the same.

And normally ./configure should define HAVE_DIRECT_H in port/cpl_config.h only if 
it is available.

> 
> I moved forward by simply commenting these lines. Unfortunately two
> GRASS modules linked to GDAL still fails to compile:
> 
> 2) r.external
> 
> OBJ.x86_64-w64-mingw32/main.o: In function `main':
> /home/landa/grass_trunk/raster/r.external/main.c:154: undefined
> reference to `_getcwd'
> /home/landa/grass_trunk/raster/r.external/main.c:154:(.text.startup+0x538):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `_getcwd'
> collect2: error: ld returned 1 exit status

Isn't that a GRASS issue since getcwd() is really called from GRASS code. I'd 
note that GDAL has a CPLGetCurrentDir() function that is essentially a wrapper 
around getcwd(). See port/cpl_path.cpp

> 
> 3) r.in.gdal
> 
> OBJ.x86_64-w64-mingw32/main.o: In function `dump_rat':
> /home/landa/grass_trunk/raster/r.in.gdal/main.c:1601: undefined
> reference to `_snprintf'
> /home/landa/grass_trunk/raster/r.in.gdal/main.c:1601:(.text.startup+0x1655)
> : relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `_snprintf'
> collect2: error: ld returned 1 exit status
> 
> I am not sure how to solve these issues correctly. Any idea?

Same here. Except when I look at 
https://svn.osgeo.org/grass/grass/trunk/raster/r.in.gdal/main.c, I see it is a 
G_snprintf() call, so perhaps you use an outdated version ? Or perhaps 
G_snprintf() is just a macro.
I know that before Visual Studio 2015, snprintf() didn't exist, and there was 
a _snprintf() function instead, but that might be unrelated to your issue with 
mingw.

> 
> Thanks in advance for any tips, Martin

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com