Opened 10 years ago

Closed 9 years ago

#827 closed defect (fixed)

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

Reported by: timmie Owned by: grass-dev@…
Priority: normal Milestone: 6.4.0
Component: Installation Version: svn-releasebranch64
Keywords: wingrass Cc: timmichelsen@…
CPU: x86-32 Platform: MSWindows XP

Description

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.

Attachments (3)

g.proj.jpg (21.6 KB) - added by timmie 10 years ago.
error message
grass.jpg (27.0 KB) - added by timmie 10 years ago.
error when running g.proj -p from msys
libtiff.jpg (27.0 KB) - added by timmie 10 years ago.
error when running g.proj -p from msys

Download all attachments as: .zip

Change History (32)

Changed 10 years ago by timmie

Attachment: g.proj.jpg added

error message

comment:1 Changed 10 years ago by timmie

Cc: timmichelsen@… added

comment:2 Changed 10 years ago by cnielsen

Keywords: wingrass added

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?

comment:3 in reply to:  2 Changed 10 years ago by 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

comment:4 Changed 10 years ago by cnielsen

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

comment:5 in reply to:  4 ; Changed 10 years ago by 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.

comment:7 in reply to:  5 ; Changed 10 years ago by 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

comment:8 Changed 10 years ago by hamish

(works fine for me on XP & wingrass r40049)

comment:9 in reply to:  7 ; Changed 10 years ago by 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

Changed 10 years ago by timmie

Attachment: grass.jpg added

error when running g.proj -p from msys

comment:10 in reply to:  8 Changed 10 years ago by 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

comment:11 Changed 10 years ago by timmie

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

comment:12 in reply to:  9 Changed 10 years ago by 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

comment:13 Changed 10 years ago by 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.

comment:14 in reply to:  13 Changed 10 years ago by 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.

comment:15 Changed 10 years ago by neteler

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

comment:16 Changed 10 years ago by hamish

see also #555

comment:17 Changed 10 years ago by 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.

comment:18 Changed 10 years ago by 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

comment:19 in reply to:  18 Changed 10 years ago by 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.

Changed 10 years ago by timmie

Attachment: libtiff.jpg added

error when running g.proj -p from msys

comment:20 Changed 10 years ago by 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.

comment:21 in reply to:  20 ; Changed 10 years ago by 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.

comment:22 in reply to:  21 ; Changed 10 years ago 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:

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.

comment:23 in reply to:  22 Changed 10 years ago by 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.

comment:24 in reply to:  21 Changed 10 years ago by 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

comment:25 Changed 10 years ago 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

comment:26 Changed 10 years ago 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.

comment:27 in reply to:  21 Changed 9 years ago by 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

comment:28 in reply to:  26 Changed 9 years ago by 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?

comment:29 Changed 9 years ago by timmie

Resolution: fixed
Status: newclosed

Can be closed. Was fixed.

Note: See TracTickets for help on using tickets.