Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#1115 closed defect (invalid)

splash image problem in wxgui

Reported by: kyngchaos Owned by: grass-dev@…
Priority: blocker Milestone: 6.4.0
Component: wxGUI Version: 6.4.0 RCs
Keywords: Cc:
CPU: OSX/Intel Platform: MacOSX


I just noticed a problem starting the wxgui on OS X 10.5 Leopard with GRASS 6.4rc6. It fails with an invalid image for the splash.

File "/Applications/",
line 1819, in <module>
File "/Applications/",
line 1812, in main
  app = GMApp(workspaceFile)
File "/Applications/",
line 1737, in __init__
  wx.App.__init__(self, False)
line 7978, in __init__
line 7552, in _BootstrapApp
File "/Applications/",
line 1748, in OnInit
  introBmp       = introImage.ConvertToBitmap()
line 3369, in ConvertToBitmap
wx._core.PyAssertionError: C++ assertion "image.Ok()" failed at
../src/mac/carbon/bitmap.cpp(1286) in wxBitmap(): invalid image

It works on OS X 10.6 Snow Leopard. Same wxpython version on both, But, python 2.5 on Leopard and 2.6 on Snow.

Happens in dev6 also.

Attachments (1)

wxgui-mac-checkpath.diff (627 bytes ) - added by aghisla 14 years ago.
debugging info on image path

Download all attachments as: .zip

Change History (7)

comment:1 by martinl, 14 years ago

Component: defaultwxGUI

comment:2 by aghisla, 14 years ago

on Debian testing I successfully compiled r42901 with:

python 2.5 and 2.6 python-wxgtk2.8 v2.8.10.1-3


by aghisla, 14 years ago

Attachment: wxgui-mac-checkpath.diff added

debugging info on image path

comment:3 by aghisla, 14 years ago

Could be an invalid image path? See the patch to display debugging info.

comment:4 by kyngchaos, 14 years ago

I tried that before submitting the bug, and the path is correct.

... just tried something else - disable the splash to skip it. Now I get the start of the GUI tool/layer window, then a crash in wx with an invalid context. Looks like I may have a bad build of wxpython. I'll try rebuilding it...

comment:5 by kyngchaos, 14 years ago

Resolution: invalid
Status: newclosed

OK, something happened in the wxpython build. Same process I always use. The only difference I could see after the rebuild was in wx-config, where in the non-working one ldlibs_core had a -lpng flag (which should be my libpng build), and in the new working one ldlibs_core is missing libpng, but ldlibs_base has a -lwxpngd.

My working Snow leopard Python 2.6-based wxpython uses my libpng. Maybe the source of the problem is my Leopard libpng...

Anyways, sorry for the noise.

comment:6 by kyngchaos, 14 years ago

Just a followup - I think I know what happened. I had originally built wxpython using libpng 1.3. Then I updated to libpng 1.4 (and trashed 1.3). libpng 1.4 replaces png_check_sig() with png_sig_cmp(). Without png_check_sig(), the old wxpython build fails. A new build used the internal libpng because 2.8.10 checks for png_check_sig().

2.8.11 checks for png_sig_cmp(). I had problems in June with 2.8.11 and the new ctypes stuff. Hopefully it's fixed now...

Note: See TracTickets for help on using tickets.