[GRASS-dev] [GRASS GIS] #827: standalone-installer: execution failed on g.proj.exe -p

GDAL · February 9, 2010, 12:51am

#827: standalone-installer: execution failed on g.proj.exe -p
---------------------------+------------------------------------------------
  Reporter: timmie | Owner: grass-dev@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>

GDAL · February 9, 2010, 8:54pm

#827: standalone-installer: execution failed on g.proj.exe -p
---------------------------+------------------------------------------------
  Reporter: timmie | Owner: grass-dev@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 timmie):

> 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).
I will conform to morrow but the computer I am experiencing this has
definately a separate version of GDAL installed:
* the binaries from the website
* python bindings: http://pypi.python.org/pypi/GDAL
* the OSGEO4W files.

> 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.
I have a lot of opensource programs installed on Windows that rely on GTK
or Python (wxPython). But all can run independatly.

Thanks for your feedback.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/827#comment:22>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 10, 2010, 12:10am

#827: standalone-installer: execution failed on g.proj.exe -p
---------------------------+------------------------------------------------
  Reporter: timmie | Owner: grass-dev@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:22 timmie]:

> I have a lot of opensource programs installed on Windows that rely on
GTK or Python (wxPython). But all can run independatly.

Note that the directory containing the executable is always searched
first. This tends to work fine for monolithic applications, but isn't
suitable for Unix-style development where a package relies upon external
packages (e.g. GRASS relying upon GDAL).

The "Windows way" is for an application to embed its own copy of every
package it depends upon. If you want to take this approach, you can move
all of GRASS' DLLs from $GISBASE/lib to $GISBASE/bin, and also copy all of
the GDAL (etc) DLLs there. OTOH, that won't work for programs which are in
$GISBASE/etc or $GISBASE/driver.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/827#comment:23>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 13, 2010, 10:40am

#827: standalone-installer: execution failed on g.proj.exe -p
---------------------------+------------------------------------------------
  Reporter: timmie | Owner: grass-dev@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 hellik):

Replying to [comment:21 glynn]:
>
> 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.

maybe this information is helpfull:
http://msdn.microsoft.com/de-de/library/aa375365(en-us,VS.85).aspx

     * Assembly manifests describe side-by-side assemblies. They are used
to manage the names, versions, resources, and dependent assemblies of
side-by-side assemblies. The manifests of shared assemblies are stored in
the WinSxS folder of the system. Private assembly manifests are stored
either as a resource in the DLL or in the application folder
     * Application manifests describe isolated applications. They are used
to manage the names and versions of shared side-by-side assemblies that
the application should bind to at run time. Application manifests are
copied into the same folder as the application executable file or included
as a resource in the application's executable file.
     * Application Configuration Files, are manifests used to override and
redirect the versions of dependent assemblies used by side-by-side
assemblies and applications.
     * Publisher Configuration Files, are manifests used to redirect the
version of a side-by-side assembly to another compatible version. The
version that the assembly is being redirected to should have the same
major.minor values as the original version.

Helmut

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/827#comment:24>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 21, 2010, 7:08pm

#827: standalone-installer: execution failed on g.proj.exe -p
---------------------------+------------------------------------------------
  Reporter: timmie | Owner: grass-dev@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 timmie):

''From a user who couldn't submit a ticket online I received this via
email:''

{{{
D:\GRASS-64-SVN>grass64svn.bat
warning: Not importing directory 'D:\GRASS-64-SVN\locale': missing
__init__.py

"Welcome to GRASS GIS" gui opens at this point, continues when "start
grass"
button is clicked

warning: Not importing directory 'D:\GRASS-64-SVN\locale': missing
__init__.py

WARNING: Vector digitizer is not available (No module named
grass6_wxvdigit).

Note that the vector digitizer is currently not working under MS Windows
(hopefully this will be fixed soon). Please keep an eye out for updated
versions of GRASS.
Traceback (most recent call last):
   File "d:/GRASS-64-SVN/etc/wxpython/wxgui.py", line 1805, in <module>
     sys.exit(main())
   File "d:/GRASS-64-SVN/etc/wxpython/wxgui.py", line 1798, in main
     app = GMApp(workspaceFile)
   File "d:/GRASS-64-SVN/etc/wxpython/wxgui.py", line 1723, in __init__
     wx.App.__init__(self, False)
   File
"C:\OSGeo4W\apps\Python25\lib\site-packages\wx-2.8-msw-
unicode\wx\_core.py",
line 7935, in __init__
   File
"C:\OSGeo4W\apps\Python25\lib\site-packages\wx-2.8-msw-
unicode\wx\_core.py",
line 7509, in _BootstrapApp
   File "d:/GRASS-64-SVN/etc/wxpython/wxgui.py", line 1741, in OnInit
     workspace = self.workspaceFile)
   File "d:/GRASS-64-SVN/etc/wxpython/wxgui.py", line 185, in __init__
     self.NewDisplay(show=False)
   File "d:/GRASS-64-SVN/etc/wxpython/wxgui.py", line 1222, in NewDisplay
     auimgr=self._auimgr, showMapDisplay=show)
   File "d:\GRASS-64-SVN\etc\wxpython\gui_modules\wxgui_utils.py", line 84,
in __init__
     self.Map = render.Map() # instance of render.Map to be associated
with display
   File "d:\GRASS-64-SVN\etc\wxpython\gui_modules\render.py", line 402, in
__init__
     self.projinfo = self.ProjInfo()
   File "d:\GRASS-64-SVN\etc\wxpython\gui_modules\render.py", line 758, in
ProjInfo
     p = gcmd.Command(['g.proj', '-p'])
   File "d:\GRASS-64-SVN\etc\wxpython\gui_modules\gcmd.py", line 356, in
__init__
     _("Error: ") + self.GetError()))
gui_modules.gcmd.CmdError

D:\GRASS-64-SVN>
}}}

she writes:

the problem may be the two lines refering to

{{{
"C:\OSGeo4W\apps\Python25\lib\site-packages\wx-2.8-msw-
unicode\wx\_core.py"
}}}

that directory does not exist on my pc

seems that part of the script is 'hard coded'

i also added output from process monitor (all references to _core.py)

if formatting is screwed up then just copy and paste into a word
prosessor,
delete all newlines, then replace with newlines and the formatting
should be restored

you will see that python is not able to locate the file after it looks for
it C:\OSGeo4W

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/827#comment:25>
GRASS GIS <http://grass.osgeo.org>

GDAL · March 1, 2010, 12:54am

#827: standalone-installer: execution failed on g.proj.exe -p
---------------------------+------------------------------------------------
  Reporter: timmie | Owner: grass-dev@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 timmie):

On a new computer / fresh Windows OS the OSGEO4W installer runs now well
without this error.

The daily builds of the standalone GRASS installer do not even lauch the
GUI due to some Python errors in the wx code.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/827#comment:26>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 6, 2010, 4:28pm

#827: standalone-installer: execution failed on g.proj.exe -p
--------------------------+-------------------------------------------------
Reporter: timmie | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Installation | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows XP
Cpu: x86-32 |
--------------------------+-------------------------------------------------

Comment(by mmetz):

Replying to [comment:21 glynn]:
>
> 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).

Exactly the same error occurred on one of the systems I maintained last
week, the culprit was a (very old) Windows/System32/libtiff.dll.
Workaround was to move this libtiff.dll to a sandbox place, only then gdal
(and consequently everything using gdal) used the correct libtiff.dll. No
idea what application installed Windows/System32/libtiff.dll. Not sure if
a manifest for g.proj or g.region would work because gdalinfo itself did
not work, same error as shown in the attached pics.

Not a solution but because this affects everything in osgeo4w that uses
gdal I would say this should not keep us from releasing 6.4.0final.

My2c,

Markus M

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/827#comment:27>
GRASS GIS <http://grass.osgeo.org>

GDAL · March 9, 2011, 10:19pm

#827: standalone-installer: execution failed on g.proj.exe -p
--------------------------+-------------------------------------------------
Reporter: timmie | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Installation | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows XP
Cpu: x86-32 |
--------------------------+-------------------------------------------------

Comment(by hellik):

Replying to [comment:26 timmie]:
> On a new computer / fresh Windows OS the OSGEO4W installer runs now well
without this error.
>
> The daily builds of the standalone GRASS installer do not even lauch the
GUI due to some Python errors in the wx code.
>

closing the ticket?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/827#comment:28>
GRASS GIS <http://grass.osgeo.org>

GDAL · March 10, 2011, 6:16am

#827: standalone-installer: execution failed on g.proj.exe -p
---------------------------+------------------------------------------------
  Reporter: timmie | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.4.0
Component: Installation | Version: svn-releasebranch64
Resolution: fixed | Keywords: wingrass
  Platform: MSWindows XP | Cpu: x86-32
---------------------------+------------------------------------------------
Changes (by timmie):

* status: new => closed
* resolution: => fixed

Comment:

Can be closed.
Was fixed.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/827#comment:29>
GRASS GIS <http://grass.osgeo.org>