[gdal-dev] Can I manually LoadLibrary(gdal16.dll) instead of
putting GDAL's bin dir in the PATH?
Jason Roberts
jason.roberts at duke.edu
Mon Dec 22 22:00:27 EST 2008
My Python application uses GDAL and OGR internally. I install a private copy
of GDAL with my app. I do not want to require the user to add GDAL's bin
directory to the PATH. To work around this, I have been manually adding the
directory to the PATH, importing the needed Python modules (e.g. osgeo.ogr),
and removing the directory from the PATH.
This strategy has worked fine until I discovered a compatibility problem
with ArcGIS, which my application also uses. Due to an apparent bug in Arc
9.3 SP1, when my application sets the PATH, a certain geoprocessing tool
will crash if I call it later, even if I reset the PATH to what it was
before. It does not matter what I set the PATH to-I can set it to its
current value, theoretically leaving it unchanged-the Arc tool will always
crash. So now I'm seeking an alternative, because getting ESRI to fix bugs
like this is generally a lost cause.
My alternative strategy is:
1. Do not mess with the PATH environment variable at all.
2. Explicitly LoadLibrary gdal16.dll by calling Python
win32api.LoadLibrary (must call SetDllDirectory first, as well)
3. Import the Python modules
So, in essence, I am wondering: to have the GDAL and OGR classes work
properly, can I just load gdal16.dll explicitly before trying the Python
bindings, rather than adding the GDAL bin directory to the PATH?
>From testing, it looks like it works, but I wanted to check with you to be
sure. I know this is kludgy but I am sadly accustomed to developing such
workarounds when dealing with ArcGIS...
Thanks for your help,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20081222/07131471/attachment-0001.html
More information about the gdal-dev
mailing list