[Gdal-dev] Windows linking to FWTools gdal_i.lib

[Roger Bivand]

On Wed, 15 Feb 2006, Roger Bivand wrote:

> On Wed, 15 Feb 2006, Frank Warmerdam wrote:
> 
> > Roger Bivand wrote:
> > > In revising and extending the R GDAL bindings, I'm using VC++ (cl) under 
> > > Windows on C API files. On Linux (GDAL 1.3.1) the references to:
> > > 
> > > OSRNewSpatialReference
> > > OSRDestroySpatialReference
> > > OSRExportToProj4
> > > OSRExportToWkt
> > > 
> > > are found and work, but give error LNK2019 in the Windows linking step
> > > when building the rgdal shared object, using Windows binary
> > > FWTools1.0.0.7a gdal_i.lib. The LNK2019 error message prepends an
> > > underscore to the function names. Curiously, it does not report that other
> > > OSR* functions are not found in this function:
> > 
> > Roger,
> > 
> > The problem is that some (but not by any means all) C entry points in
> > OGR, OSR and GDAL are exported with standard call conventions for easier
> > use from Pascal and VB6.  If you look in ogr_srs_api.h you will see the
> > CPL_STDCALL attribute applied to some functions.
> > 
> > What is less clear to me is why your compiler isn't already adjusting
> > the calls to use stdcall conventions too.   When compiling with a
> > Microsoft compiler and not explicitly defining -DCPL_DISABLE_STDCALL
> > the CPL_STDCALL macro should be expanded to __stdcall and thus the
> > application should also know to call the functions with stdcall
> > conventions.
> > 
> > You are building with VC6, VC7 or VC7.1, right?
> 
> Frank,
> 
> The linker says 7.10, so I guess it must be something like that.
> 
> My current work-around is to wrap calls to C++ versions of the unfound 
> functions in extern "C" {} in a file named *.cpp - seems to find the files 
> under Windows, I'll check that I can back-fit to gcc/g++ under Linux. I'll 
> try that first and report back, and fall back on your suggestion if I'm 
> not lucky.
> 

Replacing the C API OSR calls by C++ calls worked. The function I 
cited before (which was trying to be C in a *.c file) became (in a *.cpp 
file):

#ifdef __cplusplus
extern "C" {
#endif
#include <R.h>
#include <Rinternals.h>
#include <Rdefines.h>

SEXP p4s_to_wkt(SEXP p4s, SEXP esri) {

    OGRSpatialReference hSRS = NULL;
    char *pszSRS_WKT = NULL;
    SEXP ans;

    if (hSRS.importFromProj4(CHAR(STRING_ELT(p4s, 0))) != OGRERR_NONE)
	error("Can't parse PROJ.4-style parameter string");
    if (INTEGER_POINTER(esri)[0] == 1) hSRS.morphToESRI();
    hSRS.exportToWkt(&pszSRS_WKT);

...

and works on both Linux and Windows (linked against FWTools gdal_i.lib). 
This is easier than trying to manipulate the calls - an open door is more 
inviting than picking the lock on a closed one!

I'll be putting up an alpha release through the R-sig-geo list soon, and 
will release when users have tried it out. For now, R <-> GDAL with 
support for spatial reference works, and R <- OGR with spatial reference. 
R -> shapefile works with shapelib, and R spatial reference to WKT (eg. 
*.prj) also works. Full R -> OGR can be added if need be. In R, use is 
made of sp classes, which fit quite neatly.

Thanks again, where would we be without GDAL!

Best wishes,

Roger

> Thanks for getting back so fast!
> 
> Roger
> 
> > 
> > You might want to try and determine if CPL_STDCALL is properly being
> > defined as __stdcall in cpl_port.h (called from ogr_srs_api.h).
> > 
> > Best regards,
> > 
> 
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no