#765: g.gui fails to launch wxpython IU
--------------------+-------------------------------------------------------
Reporter: marisn | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Keywords: | Platform: Linux
Cpu: x86-64 |
--------------------+-------------------------------------------------------
When I attempt to launch new wx GUI with g.gui, I get nothing. Same applys
to 6.5 and trunk. If I switch default UI to wxpython one, it starts from
init.sh.
{{{
$ g.gui gui=wxpython
D1/5: Attempting to start 'wxpython' GUI ...
D3/5: forking 'python' ...
* status: new => closed
* resolution: => worksforme
Comment:
No one else has mentioned this since it was reported. I cannot reproduce
it. It sort of looks more like a wxwidgets/python version mismatch. I'm
closing with a 'works for me' unless someone still has this problem.
Michael, please, do NOT close bug only because it works on Your Mac! We
don't have so many testers on various systems and thus it's highly
possible that nobody else has stumbled on specific software configuration
that triggers this issue. Still I would rather love to see this bug fixed
before release and not reopened in few days after release when user
feedback will start to flow in. It still app-lays to my Gentoo system. I
made svn up && make clean on 6.5 branch and every bit of this report is
still true.
g.gui fails to launch new wxgui AND fails to report failure. init.sh works
just fine. If it's Python version mismatch, then it needs to be fixed, as
in such case g.gui and init.sh use different pythons and it may cause also
other bugs.
Same bug in the same conditions on my computer: on my Gentoo box, the
wxpython gui is working very fine if i start grass with gui, but nothing
appends when i try to launch it ussing g.gui ...
my gentoo system is uptodate and i just fetch and build the last svn
grass-6.5 release ...
I think you will have to de-fork the call in the g.gui source code in
order to more easily debug it. ie rework the G_spawn_ex() line to
something simpler like G_system().
either that or add in a bunch of debug messages to the G_spawn_ex()
function in lib/gis/ to get a better idea of what's going on.
a bit more involved than your typical debugging advice, but I assume that
folks running Gentoo don't mind poking about under the lid ...
Sorry if this is still a problem. Just no one had reported any problem on
this but you and there are often old bugs that get fixed but no one
closes. One thing that is important to sort out is if this is just a
problem with your box, a specific Gentoo version, or all Gentoo.
As to a wxPython and Python mixmatch, I was referring to the possibility
that you have installed the wrong wxPython for the Python that you are
using. The GUI doesn't install wxPython during compilation. If you are
using a pre-compiled binary (it doesn't say in the report), this might be
important. For Mac and Windows, bundling wxPython with the binary solved a
lot of issues. I don't know if this is feasible on Linux or not. If it is,
it might be worth considering.
> It still app-lays to my Gentoo system. I made svn up && make clean on
6.5 branch
> and every bit of this report is still true.
>
> g.gui fails to launch new wxgui AND fails to report failure.
It's a Gentoo bug. Gentoo's `/usr/bin/python` is a symlink to `python-
wrapper` which invokes the version of python selected by
`/etc/env.d/python/config`, `$EPYTHON`, etc.
Unfortunately, it also inspects `argv[0]` (which it has no business
doing), which breaks when `argv[0]` is something other than the Python
interpreter or the script.
g.gui passed "wxgui" as `argv[0]`; I "fixed" this in 7.0 with r39764, but
that was before I discovered that it was Gentoo's bug. I'm not sure
whether this should be back-ported or reverted.
As to what to do about it: part of me says to revert it on principle
(Gentoo isn't Microsoft, and shouldn't assume that the rest of the world
will change to accommodate them). OTOH, I don't see any advantage to
passing an "unusual" value for `argv[0]`.
Replying to [comment:7 cmbarton]:
> Does it work if you give the full version of the command ("g.gui
gui=wxpython&") instead of the short version ("g.gui &" or "g.gui
wxpython&")?
No. The arguments to g.gui don't have any effect upon `argv[0]`; it won't
work on Gentoo without the r39764 change.
Replying to [comment:7 cmbarton]:
> Does it work if you give the full version of the command
> ("g.gui gui=wxpython&") instead of the short version ("g.gui &"
> or "g.gui wxpython&")?
note the "&" should no longer be needed. It backgrounds itself (wait 3
sec).
Replying to [comment:11 cmbarton]:
> Unfortunately, the "&" is still needed on the Mac. Run it without the
"&" and the GUI runs modally. I wish it were otherwise.
Which version are you referring to?
7.0 (trunk) and 6.5 (develbranch_6) run it in the background, 6.4
(releasebranch_6_4) runs it in the foreground.
Glynn - thanks for hints. Indeed it's a broken python-wrapper. Closing
this bug, as it's a Gentoo issue. After fixing segfault, g.gui now
launches wxpython interface. Still ps fax says "python2.6 /path/to/wxgui".
Does some wgui code relays on argv[0] == wxgui?
Gentoo python-wrapper.c has been written by similar skilled C coders, as
I. char *foo = NULL; if(*foo) -> segfault Damn' pointers!
> Glynn - thanks for hints. Indeed it's a broken python-wrapper. Closing
this bug, as it's a Gentoo issue. After fixing segfault, g.gui now
launches wxpython interface. Still ps fax says "python2.6 /path/to/wxgui".
Does some wgui code relays on `argv[0]` == wxgui?
I'm fairly sure that wxgui doesn't care what `argv[0]` is set to. But
setting it to the full path to the script is "normal" and keeps python-
wrapper happy.
Damn' pointers!