Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

[Tamas Szekeres]

2011/1/6 Christopher Barker <Chris.Barker at noaa.gov>

> I notice on my system, the dll is "gdal17.dll"
>
> That is, the version is part of the file name, so there shouldn't be a
> problem with different versions installed in the PATH.
>
> WE could even use a longer filename, like *nix systems, we're not
> restricted to 8.3 anymore, are we?
>
> gdal-1.7.1-a.dll
>
>
Chris,

This is where a typical dll hell problem is starting. The application is
happy to load a common dll let's say a gdal17.dll, zlib1.dll, libcurl.dll
whatever, but is not the same at it is expected to be (for example it
depends on different CRT libraries). The issue is that you rarely get a
clear error message what the problem is, but your application is failing
with access violations in certain conditions.

To make sure about the issue I did a quick test on my devserver with a
whereis.bat containing the following script, trying to find the location of
some common dlls (used by gdal):

@for %%e in (%PATHEXT%;.dll) do @for %%i in (%1%%e) do @if NOT
"%%~$PATH:i"=="" echo %%~$PATH:i


E:\builds>whereis zlib1
C:\Program Files (x86)\Mono-1.2.6\bin\zlib1.dll

E:\builds>whereis ssleay32
C:\Program Files (x86)\Subversion\ssleay32.dll

Depending on the location of my entry in the PATH may break both
applications or these files may break mine.

Not sure this causes an issue in this particular case but, it makes the
things fragile well enough.

Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110106/c2721a51/attachment.html