[gdal-dev] GDALDestroyDriverManager() and static driver pointers

Frank Warmerdam warmerdam at p...
Wed Sep 4 08:27:18 EDT 2002

Paul Selormey wrote:

>I have many wishes, but you know they are not horses :-) 


This must be an idiom I am not familiar with.

>I also wished the
>various drivers were implemented as share library (dll for Windows). That
>I could simply take GeoTiff, if that is all that I want in an application.
In fact, there is support for auto-loading drivers from a shared 
library. The GDALDriverManager will
auto load drivers from any file named gdal_<drivername>.so in the gdal 
driver path, and then call
GDALRegister_<drivername> within that file to register it. The driver 
path is read from the
GDAL_DRIVER_PATH environment variable and defaults to /usr/local/lib if 
nothing else is found.
The auto-load support is invoked as soon as the GDALDriverManager is 
first constructed.

It isn't currently used by anyone, as far as I know. It was intended to 
make it possible to add drivers
to pre-built GDAL binary distributions, including potentially 
proprietary driver or drivers with lots
of dependencies that it might not be desireable to have in a core build.

As we discussed a few months ago, drivers are fairly sensitive to 
changes in GDAL version due to
changes in the base classes which are subclassed by drivers, so 
generally such standalone drivers
would need to be compiled for pretty much exactly the matching GDAL version.

>In fact, if
>there is no need to use GDAL to access a GeoTiff file, I could also use the
>library directly.
Well, the drivers aren't really useful all on their own and it isn't my 
intention that they be.

Best regards,

I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at p...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

More information about the Gdal-dev mailing list