[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