[gdal-dev] GDAL 1.5.0 (RC2) Binaries

[mchapman at texelinc.com]

Howard,

Thank you very much for that information.  

So, then I assume that a good client process of gdalxx.dll would ensure that the dependencies of the gdal plugins are correctly in the path and would resolve any issues before gdal is loaded?  

Could this be done by removing the plugin dll from the plugin directory if the dependency path could not be validated?

Best regards,
Martin



Sent via BlackBerry by AT&T

-----Original Message-----
From: Howard Butler <hobu.inc at gmail.com>

Date: Wed, 26 Dec 2007 22:08:41 
To:Martin Chapman <mchapman at texelinc.com>
Cc:"'Frank Warmerdam'" <warmerdam at pobox.com>, "'gdal-dev'" <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] GDAL 1.5.0 (RC2) Binaries



On Dec 26, 2007, at 9:29 PM, Martin Chapman wrote:

> Howard,
>
> How do the plugins work?  Do you compile the plugin against the driver
> library and then distribute the driver and it only loads if the  
> dependent
> format driver is present on the users machine?  Thanks for whatever  
> insight
> you have time to provide.

The plugins work by linking the driver specific code (mrsid, ECW,  
ArcSDE, whatver) into its own dll (for example ogr_SDE.dll -- the OGR  
ArcSDE driver) and then linking that against both the gdal15.dll and  
any driver-specific libraries that the driver might need.

Taking the OGR SDE driver, it links against gdal15.dll, sde91.dll, and  
sg91.dll (maybe a few others too).  When you put this in the  
gdalplugins directory, or override the location where GDAL should look  
with GDAL_DRIVER_PATH, GDAL will recognize the plugin dll because of  
the naming convention and dynamically load and register the driver at  
runtime.

Of course, this only works if the requisite dlls that ogr_SDE.dll (The  
ArcSDE SDK dlls) are available on the path to be loaded at runtime.   
If it can't, you'll sometimes get some rather cryptic error messages.   
I've found the best way to diagnose missing dll loading problems is to  
run from a cmd.exe, where Windows doesn't swallow the popup window  
saying which dll it can't find.

All of the above should apply to .so's on Linux/OSX as well, without  
the Windows misery :)  Of course, building your own on these  
environments isn't as challenging or aggravating, so the plugin  
mechanism isn't as compelling.

Howard