[Gdal-dev] SWIG and dynamic versus static libraries

[Charlie Savage]

Here is another interesting one that came up testing the Ruby SWIG 
bindings for OSR.

When testing a State Plane coordinate system, GDAL output a warning that 
it could not find "stateplane.csv."  It turns out this happened because 
GDAL couldn't find the GDAL directory.

You can fix this by calling CPLSetConfigOption.  This API is exposed in 
the gdal module, but not in the osr module.  So the Ruby code:

Gdal::Gdal.set_config_option('GDAL_DATA', dir)
srs = Gdal::Osr::SpatialReference.new
srs.set_state_plane(403, 1) # California III NAD83

But this didn't work. The reason is because I have been compiling the 
Ruby extensions against the Windows static library and not the DLL - 
thus the GDAL module and the ORS modules each have their own memory area 
for the various CPL variables.

What is the best way to handle this:

1.  Require that extensions for all languages must compile against the 
DLL on windows and shared libraries on Linux?  From what I can see, this 
is what the Python extension is doing (it ignores the DLLBUILD option in 
  gdal/nmake.opt)

2.  Expose the CPL APIs (there about ten methods exposed via SWIG right 
now) in each module (GDAL, OGR, OSR), thereby allowing either static or 
dynamic linking?

Thanks,

Charlie