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

[Even Rouault]

Le jeudi 10 décembre 2015 10:41:20, Martin Landa a écrit :
> Hi,
> 
> 2015-12-10 10:27 GMT+01:00 Even Rouault <even.rouault at spatialys.com>:
> > And normally ./configure should define HAVE_DIRECT_H in port/cpl_config.h
> > only if it is available.
> 
> to be more precise, I am building GRASS against GDAL shipped via
> OSGeo4W (which has HAVE_DIRECT_H already defined). I didn't find this
> header in OSGeo4W framework.
> 
> >> 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+0x53
> >> 8): 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
> 
> getcwd() is used on other places in GRASS, the only failing is
> r.external which is linked to GDAL. I found out that GDAL defines:
> 
> #ifndef getcwd
> #define getcwd _getcwd
> #endif
> 
> Could be this the issue?

Definitely. As pointed by Jürgen you're playing a dangerous game here re-using  
with mingw the cpl_config.h designed to work with MSVC.
This allias of getcwd to _getcwd is for MSVC only.
To work around this issue you could just #define getcwd getcwd before including 
GDAL headers.
Actually if we are honest the issue is that GDAL public headers shouldn't 
ideally expose such things which should be kept in private headers not 
installed, but that would be hard to fix. There's a ticket in the tracker about 
that. Would probably require editing all GDAL files...

> 
> Martin

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