[gdal-dev] direct.h and other Windows issue
even.rouault at spatialys.com
Thu Dec 10 01:49:39 PST 2015
Le jeudi 10 décembre 2015 10:41:20, Martin Landa a écrit :
> 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
> 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
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...
Spatialys - Geospatial professional services
More information about the gdal-dev