[Gdal-dev] Incorrect plugin search when registering GDAL drivers

[Marek Brudka]

Hi,
I've reported the following error in bugzilla 
(http://208.24.120.44/show_bug.cgi?id=746).

This bug is related with void GDALDriverManager::AutoLoadDrivers() 
method. The way this method works leads to errors, which manifest under 
windows, though it is possible other systems are also affected.
Method GDALDriverManager::AutoLoadDrivers() tries to load every file 
found in papszSearchPath starting with gdal_. For GDAL_DRIVER_PATH 
defined this is quite resonable. However when GDAL_DRIVER_PATH is 
undefined, method tries to load files from /usr/local/lib path, which is 
frequently used for storing other import libraries. Obviously, loading 
import library as shared one results in linking errors. To fix this bug, 
GDALDriverManager::AutoLoadDrivers() method should check if given file 
is  shared library before loading.
The current plugin loading is rather badly designed. I propose to change 
the functionality of GDALDriverManager::AutoLoadDrivers() as follows:
1. AutoLoadDrives should be parameterized be a search path.
2. GDAL_DRIVER_PATH should not be defined at gdal library level, but 
rather at the user application one. Every environment variable 
introduces configuration and deployment problems, hence they should be 
avoided. Otherwise configuration of the application becomes a nightmare.
3. RegisterAllDrivers should be parameterized by a search path, possible 
with NULL default.
4. Every file processed by GDALDriverManager::AutoLoadDrivers() should 
be verified if it is real shared library.
5. Every shared library should be check against compilation variant. 
Loading dll compiled in Debug mode in release version of the library 
often leads to critical errors. As a rule of thumb, one should never mix 
Debug and Release variants under Windows. (this is hard issue).

I think that plugin architecture of GDAL requires wide discussion in the 
context of GDAL build system.

Marek Brudka