[gdal-dev] Re: Swig-problem, possibly

Tomas R monshi at home.se
Wed Jul 21 06:50:31 EDT 2010


  It seem like, after a friend checked the wrap-files with Dependency 
Walker, that there are references to msvcr100.dll and msvp100.dll which, 
as far as I know, are runtime files from Visual Studio 2010.
is that really as it should be? Should really the result depend on files 
from the environment it was compiled in? Must I go back to VSE2008 and 
recompile Gdal to make it work on all machines or is there a setting 
somewhere...


Yours
Tomas

Tomas R skrev 2010-07-21 09:25:
>  I have a Gdal-plugin for the eminent program SportTracks. This plugin 
> gives access to the Gdal libraries for other plugins of the program.
> Works great, normally.
>
> But on some, or possibly all, WinXP computers it fails. It fails 
> setting up the environment for the plugin, the path.
>
> The plugin is written in C#, targeted at .Net2 and also the bindings 
> and Gdal is compiled with .Net2.  Below is the code and the exception 
> I get.
> Anyone with an idea why this fails on WinXp? I have confirmed the 
> problem on an updated WinXp computer with .Net2 and .Net3.5 installed.
>
>
> The code is, in short, like this:
>
> path = Environment.GetEnvironmentVariable("PATH");
> installPath = 
> Path.Combine(Path.GetDirectoryName(this.GetType().Assembly.Location),"Gdalbin") 
> ;
> path = installPath + ";" + path;
> Environment.SetEnvironmentVariable("PATH", path);
> OSGeo.GDAL.Gdal.SetConfigOption("GDAL_DATA", Path.Combine(installPath, 
> "data"));
>
> and it fails on the last line above, it fails to locate/link to the 
> correct DLL even though the path is correct and the DLLs exist at the 
> end of the path. I have tested with a shorter path and checked the 
> framework version of the DLLs at runtime, the managed DLLs that is.
>
> It throws the following exception:
>
> System.TypeInitializationException: The type initializer for 
> 'OSGeo.GDAL.GdalPINVOKE' threw an exception. ---> 
> System.TypeInitializationException: The type initializer for 
> 'SWIGExceptionHelper' threw an exception. ---> 
> System.DllNotFoundException: Unable to load DLL 'gdal_wrap': The 
> specified module could not be found. (Exception from HRESULT: 0x8007007E)
> at 
> OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate 
> applicationDelegate, ExceptionDelegate arithmeticDelegate, 
> ExceptionDelegate divideByZeroDelegate, ExceptionDelegate 
> indexOutOfRangeDelegate, ExceptionDelegate invalidCastDelegate, 
> ExceptionDelegate invalidOperationDelegate, ExceptionDelegate 
> ioDelegate, ExceptionDelegate nullReferenceDelegate, ExceptionDelegate 
> outOfMemoryDelegate, ExceptionDelegate overflowDelegate, 
> ExceptionDelegate systemExceptionDelegate)
> at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
> --- End of inner exception stack trace ---
> at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
> at OSGeo.GDAL.GdalPINVOKE..cctor()
> --- End of inner exception stack trace ---
> at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
> at OSGeo.GDAL.Gdal.SetConfigOption(String pszKey, String pszValue)
> at GDALPlugin.Gdal_Interface..ctor()
>
> please, I am at a loss here.
> The path is correct. Is it a framework problem?



More information about the gdal-dev mailing list