[Gdal-dev] Re: SWIG and dynamic versus static libraries

[Charlie Savage]

That would work well for linking to dynamic libraries, but it won't work 
for statically linking because the CPL module will just be its own DLL.

Thus when the OSR module calls GetConfigOption it will look to the CPL 
methods in its DLL (which it has via various includes), and not the 
shared one that is exposed to the target language.  Or at least that's 
my interpretation of what I'm seeing when statically linking.

I tend to lean towards exposing the CPL methods in all modules...but not 
sure if that will cause some other unforeseen issues.


Charlie

Kevin Ruland wrote:
> Charlie,
> 
> I always thought it was unusal that the cpl methods were only in gdal. 
> This was a mostly historical problem.
> 
> One of the things I thought of early on was to create a cpl module which
> was all the cpl function.  This does introduce another namespace,
> though.  In python, I would then trick it with "from cpl import *" in
> the pythoncode header for each modules.  Ideally you'd have a mechanism
> like that in ruby as well.
> 
> This might actually work to cleaning up the errorhandler confusion as well.
> 
> Kevin
> 
> 
> 
> Charlie Savage wrote:
> 
>> 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
>>
>> _______________________________________________
>> Gdal-dev mailing list
>> Gdal-dev at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/gdal-dev