#765 closed defect (invalid)
g.gui fails to launch wxpython IU
| Reported by: | marisn | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 6.4.0 |
| Component: | wxGUI | Version: | 6.4.0 RCs |
| Keywords: | Cc: | ||
| CPU: | x86-64 | Platform: | Linux |
Description
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' ... $ echo $? 0 $ env | grep -i python GRASS_PYTHON=python PYTHONPATH=/home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/etc/python $ python --version Python 2.6.2 glacier ~ # equery l '*wx*' * Searching for *wx* ... [IP-] [ ~] app-admin/eselect-wxwidgets-1.1 (0) [IP-] [ ~] dev-python/wxpython-2.8.10.1 (2.8) [IP-] [ ~] x11-libs/wxGTK-2.8.10.1-r3 (2.8) glacier ~ # equery l '*python*' * Searching for *python* ... [IP-] [ ~] app-admin/eselect-python-20090824 (0) [IP-] [ ~] app-admin/python-updater-0.7 (0) [IP-] [ ] dev-lang/python-2.4.6 (2.4) [I-O] [M ] dev-lang/python-2.5.4-r2 (2.5) [IP-] [ ~] dev-lang/python-2.6.2-r2 (2.6) [IP-] [ ~] dev-lang/python-3.1.1-r1 (3.1) [IP-] [ ~] dev-python/dbus-python-0.83.0-r1 (0) [IP-] [ ~] dev-python/mysql-python-1.2.3_rc1 (0) [IP-] [ ] dev-python/notify-python-0.1.1-r1 (0) [IP-] [ ~] dev-python/wxpython-2.8.10.1 (2.8)
Change History (15)
comment:1 by , 14 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
follow-up: 6 comment:2 by , 14 years ago
| Resolution: | worksforme |
|---|---|
| Status: | closed → reopened |
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.
Updated bits:
# python --version Python 2.6.4 # equery l '*python*' [IP-] [ ~] app-admin/eselect-python-20090824 (0) [IP-] [ ~] app-admin/python-updater-0.7 (0) [IP-] [ ] dev-lang/python-2.4.6 (2.4) [I-O] [M ] dev-lang/python-2.5.4-r2 (2.5) [IP-] [ ~] dev-lang/python-2.6.4 (2.6) [IP-] [ ~] dev-lang/python-3.1.1-r1 (3.1) [IP-] [ ~] dev-python/dbus-python-0.83.0-r1 (0) [IP-] [ ~] dev-python/mysql-python-1.2.3_rc1 (0) [IP-] [ ] dev-python/notify-python-0.1.1-r1 (0) [IP-] [ ~] dev-python/wxpython-2.8.10.1 (2.8) [IP-] [ ~] kde-base/krosspython-4.3.4 (4.3)
comment:3 by , 14 years ago
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 ...
GRASS 6.5.svn :~ > g.gui gui=wxpython D1/5: Attempting to start 'wxpython' GUI ... GRASS 6.5.svn (Mac):~ > echo $? 0 GRASS 6.5.svn :~ > env | grep -i python GRASS_PYTHON=python PYTHONPATH=/opt/grass65/grass-6.5.svn/etc/python GRASS 6.5.svn :~ > python --version Python 2.6.4 SuperTux yarma # equery list wx [ Searching for package 'wx' in all categories among: ] * installed packages [I--] [ ~] app-admin/eselect-wxwidgets-1.1 (0) [I--] [ ] dev-python/wxpython-2.8.10.1 (2.8) [I--] [ ~] x11-libs/wxGTK-2.8.10.1-r3 (2.8) SuperTux yarma # equery list python [ Searching for package 'python' in all categories among: ] * installed packages [I--] [ ~] app-admin/eselect-python-20090824 (0) [I--] [ ] app-admin/python-updater-0.7 (0) [I--] [ ] dev-lang/python-2.6.4 (2.6) [I--] [ ] dev-python/bug-buddy-python-2.26.0 (0) [I--] [M~] dev-python/compizconfig-python-0.8.2 (0) [I--] [ ] dev-python/dbus-python-0.83.0-r1 (0) [I--] [ ] dev-python/gconf-python-2.26.1 (2) [I--] [ ] dev-python/gnome-applets-python-2.26.0 (0) [I--] [ ] dev-python/gnome-desktop-python-2.26.0 (0) [I--] [ ] dev-python/gnome-keyring-python-2.26.0 (0) [I--] [ ] dev-python/gnome-python-2.26.1 (2) [I--] [ ] dev-python/gnome-python-base-2.26.1 (2) [I--] [ ] dev-python/gnome-python-desktop-base-2.26.0 (0) [I--] [ ] dev-python/gnome-vfs-python-2.26.1 (2) [I--] [ ] dev-python/gst-python-0.10.16 (0.10) [I--] [ ] dev-python/libbonobo-python-2.26.1 (2) [I--] [ ] dev-python/libgnome-python-2.26.1 (2) [I--] [ ] dev-python/libgnomecanvas-python-2.26.1 (2) [I--] [ ] dev-python/libgnomeprint-python-2.26.0 (0) [I--] [ ] dev-python/libwnck-python-2.26.0 (0) [I--] [ ] dev-python/python-ldap-2.3.9 (0) [I--] [ ] dev-python/wxpython-2.8.10.1 (2.8)
comment:4 by , 14 years ago
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 ...
Hamish
comment:5 by , 14 years ago
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.
Michael
Michael
comment:6 by , 14 years ago
Replying to marisn:
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.
This bug has been reported at http://bugs.gentoo.org/show_bug.cgi?id=286191, but the Gentoo developers only appear to be concerned with how it affects Gentoo itself.
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].
follow-ups: 8 9 comment:7 by , 14 years ago
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&")?
Michael
follow-up: 10 comment:8 by , 14 years ago
comment:9 by , 14 years ago
Replying to 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).
comment:10 by , 14 years ago
Replying to glynn:
The arguments to g.gui don't have any effect upon
argv[0]; it won't work on Gentoo without the r39764 change.
maybe the emerge script for gentoo could apply the needed patch as needed?
(eg the Debian package applies a series of patches to satisfy various debian-specific quirks which are not relevant to other platforms)
Hamish
follow-up: 12 comment:11 by , 14 years ago
Unfortunately, the "&" is still needed on the Mac. Run it without the "&" and the GUI runs modally. I wish it were otherwise.
Michael
comment:12 by , 14 years ago
Replying to 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.
comment:13 by , 14 years ago
I stand corrected!
I didn't notice, probably because I go back and forth between versions. Thanks very much.
Michael
follow-up: 15 comment:14 by , 14 years ago
| Resolution: | → invalid |
|---|---|
| Status: | reopened → closed |
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!
comment:15 by , 14 years ago
Replying to marisn:
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.
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.