[GRASS-dev] Re: [GRASS GIS] #827: standalone-installer: execution
failed on g.proj.exe -p
GRASS GIS
trac at osgeo.org
Mon Feb 8 19:51:20 EST 2010
#827: standalone-installer: execution failed on g.proj.exe -p
---------------------------+------------------------------------------------
Reporter: timmie | Owner: grass-dev at lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Installation | Version: svn-releasebranch64
Resolution: | Keywords: wingrass
Platform: MSWindows XP | Cpu: x86-32
---------------------------+------------------------------------------------
Comment (by glynn):
Replying to [comment:20 timmie]:
> what can I do to help debugging this?
>
> I does not work neither with wxPython nor with TCLTK.
>
> All report that there is either a problem with g.region or g.proj.
The obvious common factor between g.region and g.proj is GDAL.
I would guess that the libtiff.dll which is being loaded isn't the one
which GDAL wants. You can use [http://www.dependencywalker.com/ Dependency
Walker] to determine where libraries are being loaded from.
The %PATH% environment variable is the last resort for locating libraries,
so if there is a libtiff.dll in e.g. Windows or Windows/System32, it will
take precedence. The only locations which are ahead of the Windows
directories are the executable's directory (i.e. $GISBASE/bin) and any "
Side-by-Side Assemblies" specified in the program's manifest (if it has
one).
We're already faced with having to create manifests to keep UAC happy, so
it would be useful if someone could read up on this stuff and figure out
how to use manifests to control searching for DLLs.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/827#comment:21>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list