standalone-installer: execution failed on g.proj.exe -p

[timmie]

It is not possible to execute the GRASS on the most recent Windows installer.

Version: ​http://grass.itc.it/grass64/binary/mswindows/native/WinGRASS-6.4.0svn-r39740-2-Setup.exe (16-11-2009).

A sceenshot is attached.

[timmie]

error message

[cnielsen]

No problems here, can you give some more detail on the steps leading up to the error? Which GUI were you trying to load? Was this a new location, what coordinate system?

[hellik]

Replying to cnielsen:

No problems here, can you give some more detail on the steps leading up to the error? Which GUI were you trying to load? Was this a new location, what coordinate system?

a quick test on a very old Win XP-box:

by defining a new location with the wx-gui the same error comes up. I can't test this on my WinVista.

Helmut

[cnielsen]

Still not sure what caused this problem to begin with but please test with the new installer.

[kmithoefer]

Replying to cnielsen:

Still not sure what caused this problem to begin with but please test with the new installer.

I have the same problem. I installed WinGRASS-6.4.0svn-r39740-2-Setup.exe on Windows XP professional. I start C:\GRASS\grass64.bat -wxpython and choose the spearfish database and start GRASS. Then I get the message Execution failed g.proj.exe -p . There is python 2.4 and 2.5 installed.

[timmie]

The problem persist on my machine with: ​http://grass.osgeo.org/grass64/binary/mswindows/native/WinGRASS-6.4.0SVN-r40049-1-Setup.exe

[hamish]

Replying to kmithoefer:

I start C:\GRASS\grass64.bat -wxpython and choose the spearfish database and start GRASS. Then I get the message Execution failed g.proj.exe -p .

does it work using the old tcltk GUI? can you run 'g.proj -p' from the GRASS+MSys command line prompt?

There is python 2.4 and 2.5 installed.

anyone else see this problem? if so, do you also have multiple pythons installed? which ones? (be as precise as possible please)

Hamish

[hamish]

(works fine for me on XP & wingrass r40049)

[timmie]

Replying to hamish:

Replying to kmithoefer:

I start C:\GRASS\grass64.bat -wxpython and choose the spearfish database and start GRASS. Then I get the message Execution failed g.proj.exe -p .

does it work using the old tcltk GUI?

Not for me.

can you run 'g.proj -p' from the GRASS+MSys command line prompt?

no. see attached acreenshot

There is python 2.4 and 2.5 installed.

I have Python26 in C:\Python26

[timmie]

error when running g.proj -p from msys

[hellik]

Replying to hamish:

(works fine for me on XP & wingrass r40049)

works on WinVista32 & r40049, both from msys-command-line and from wx-gui-command-line

Helmut

[timmie]

So what is wrong with my setting? Maybe previous versions haven't been deinstalled correctly?

[hamish]

does it work using the old tcltk GUI?

Replying to timmie:

Not for me.

can you run 'g.proj -p' from the GRASS+MSys command line prompt?

no. see attached acreenshot

ok, so not a python problem at all, as tcl and the command line do not use python.

it would be better if you could just type out and translate error messages for us, especially if it is just one sentence. cheers

looking at the screenshot I see someing about a missing function in libtiff.dll?? That would indicate that it was built for one version of libtiff but is finding another, older one.

Did you have the same problem with the last installer? (Colin, you are building on XP, while Helmut is building on Vista, right?)

Hamish

[cnielsen]

I build on vista, I think we both do. (I test on xp-64 as well). I think libtiff was updated in osgeo4w recently... perhaps there is a problem there. But no issue on my system.

[timmie]

Replying to cnielsen:

I build on vista, I think we both do. (I test on xp-64 as well). I think libtiff was updated in osgeo4w recently... perhaps there is a problem there. But no issue on my system.

I have installed the standalone GRASS and the full OSGEO4W package. Could it be that they conflict?

The GRASS version from OSGEO4W is quite outdated. The problem is that GRASS support for QGIS is only provided within the OSGEO distribution.

[neteler]

Does the problem persist with a recent installer from ​http://josef.fsv.cvut.cz/wingrass/grass64/ ?

[hamish]

see also #555

[timmie]

Yesterday I tried the 64 and 65 installer from above mentioned site. None worked.

The error given on the MSYS CLI:

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



Note that the vector digitizer is currently not working under MS Windows (hopefu                                                                        lly this will be fixed soon). Please keep an eye out for updated versions of GRA                                                                        SS.

Traceback (most recent call last):

  File "c:/GRASS-65-SVN/etc/wxpython/wxgui.py", line 1695, in <module>

    sys.exit(main())

  File "c:/GRASS-65-SVN/etc/wxpython/wxgui.py", line 1688, in main

    app = GMApp(workspaceFile)

  File "c:/GRASS-65-SVN/etc/wxpython/wxgui.py", line 1610, in __init__

    wx.App.__init__(self, False)

  File "C:\OSGeo4W\apps\Python25\lib\site-packages\wx-2.8-msw-unicode\wx\_core.p                                                                        y", line 7935, in __init__

    self._BootstrapApp()

  File "C:\OSGeo4W\apps\Python25\lib\site-packages\wx-2.8-msw-unicode\wx\_core.p                                                                        y", line 7509, in _BootstrapApp

    return _core_.PyApp__BootstrapApp(*args, **kwargs)

  File "c:/GRASS-65-SVN/etc/wxpython/wxgui.py", line 1631, in OnInit

    workspace = self.workspaceFile)

  File "c:/GRASS-65-SVN/etc/wxpython/wxgui.py", line 175, in __init__

    self.NewDisplay(show=False)

  File "c:/GRASS-65-SVN/etc/wxpython/wxgui.py", line 1211, in NewDisplay

    auimgr=self._auimgr, showMapDisplay=show)

  File "C:\GRASS-65-SVN\etc\wxpython\gui_modules\wxgui_utils.py", line 108, in _                                                                        _init__

    Map=self.Map, auimgr=self.auimgr)

  File "c:/osgeo4w/usr/src/grass6_devel/dist.i686-pc-mingw32/etc/wxpython/gui_mo                                                                        dules/mapdisp.py", line 288, in __init__

KeyError: 'n'

I suppose that there is still a conflict with the Python installation at: C:\python26 on my machine.

[hamish]

can you run "g.proj -p" from the GRASS> terminal command line when starting GRASS in text mode, without any GUI? what error do you get? if you run "echo $?" directly after it dies what does that say?

Hamish

[timmie]

Replying to hamish:

can you run "g.proj -p" from the GRASS> terminal command line when starting GRASS in text mode, without any GUI? what error do you get?

a libtiff.dll error. I attach a screenshot.

if you run "echo $?" directly after it dies what does that say?

Nothing.

[timmie]

error when running g.proj -p from msys

[timmie]

Hello, 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.

[glynn]

Replying to 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 ​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.

[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.

[glynn]

Replying to 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.

[hellik]

Replying to 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%28en-us,VS.85%29.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

[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

[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.

[mmetz]

Replying to 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 ​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

[hellik]

Replying to 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?

[timmie]

Can be closed. Was fixed.