Hello friends,
I tried again to build an inkscape aqua… I uninstalled all X11-related components first, than reinstalled the quartz/aqua variants, finally did a selfupdate above all.
I ended up with an inkscape build which launches, shows a window for a fraction of a second, and than crashes.
Here are the terminal messages:
** (inkscape:630): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed
** (inkscape:630): WARNING **: Unable to read keys file Contents/ Resources/keys/default.xml Unable to find: org.inkscape.help.manual Unable to find: org.inkscape.help.keys Unable to find: org.inkscape.help.askaquestion Unable to find: org.inkscape.help.commandline Unable to find: org.inkscape.help.faq Unable to find: org.inkscape.help.relnotes Unable to find: org.inkscape.help.reportabug Unable to find: org.inkscape.help.svgspec
(inkscape:630): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed
(inkscape:630): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed
As far as I remember, similar messages occured when launching my working version last year, so probabely we dont have to care too much on that.
These are a few lines from crash reporter:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
Thread 0 Crashed: 0 <<00000000>> 0x00000000 0 + 0 1 libgdk-quartz-2.0.0.dylib 0x02347c44 gdk_window_destroy + 36 2 libgtk-quartz-2.0.0.dylib 0x021100b8 gtk_widget_real_unrealize
- 168
3 inkscape 0x00140af0 sp_canvas_unrealize (_GtkWidget*) + 320 4 libgobject-2.0.0.dylib 0x0251a014 g_closure_invoke + 436 5 libgobject-2.0.0.dylib 0x0252cfcc signal_emit_unlocked_R + 3452 6 libgobject-2.0.0.dylib 0x0252e30c g_signal_emit_valist + 2012 7 libgobject-2.0.0.dylib 0x0252e580 g_signal_emit + 48 8 libgtk-quartz-2.0.0.dylib 0x0210c5e0 gtk_widget_unrealize + 256 9 libgtk-quartz-2.0.0.dylib 0x0206fa3c gtk_table_forall + 76 10 libgtk-quartz-2.0.0.dylib 0x02110090 gtk_widget_real_unrealize
- 128
11 libgobject-2.0.0.dylib 0x0251a014 g_closure_invoke + 436 12 libgobject-2.0.0.dylib 0x0252cfcc signal_emit_unlocked_R + 3452 13 libgobject-2.0.0.dylib 0x0252e30c g_signal_emit_valist + 2012 14 libgobject-2.0.0.dylib 0x0252e580 g_signal_emit + 48 15 libgtk-quartz-2.0.0.dylib 0x0210c5e0 gtk_widget_unrealize + 256 16 libgtk-quartz-2.0.0.dylib 0x0200935c gtk_paned_forall + 124 17 libgtk-quartz-2.0.0.dylib 0x02110090 gtk_widget_real_unrealize
- 128
18 libgobject-2.0.0.dylib 0x0251a014 g_closure_invoke + 436 19 libgobject-2.0.0.dylib 0x0252cfcc signal_emit_unlocked_R + 3452 20 libgobject-2.0.0.dylib 0x0252e30c g_signal_emit_valist + 2012 21 libgobject-2.0.0.dylib 0x0252e580 g_signal_emit + 48 22 libgtk-quartz-2.0.0.dylib 0x0210c5e0 gtk_widget_unrealize + 256
I can find some google hits on "gdk_window_destroy" - but its far ahead my knowledge to draw any wisdom from it.
I'd be grateful for some hints where to start research - inkscape, macports, gtk2 ?? - Who is the person (list, forum) to ask first - any hints would be appreciated.
Yours
Wolf
On Feb 10, 2010, at 5:08 AM, Wolf Drechsel wrote:
Hello friends,
I tried again to build an inkscape aqua… I uninstalled all X11-related components first, than reinstalled the quartz/aqua variants, finally did a selfupdate above all.
I ended up with an inkscape build which launches, shows a window for a fraction of a second, and than crashes.
Here are the terminal messages:
** (inkscape:630): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed
** (inkscape:630): WARNING **: Unable to read keys file Contents/ Resources/keys/default.xml
That looks like it is trying to find packaged resources that have been built up into an Inkscape.app folder/bundle. It probably needs to be packaged up and then run from there.
** (inkscape:630): WARNING **: Unable to read keys file Contents/ Resources/keys/default.xml
That looks like it is trying to find packaged resources that have been built up into an Inkscape.app folder/bundle. It probably needs to be packaged up and then run from there.
Hello,
thanks to Jon's hint I packaged the inkscape-aqua-build, did some patching with gtk2 (thanks to ~suv for the hint) according to this ticket
http://trac.macports.org/ticket/22451
(Details will be in the wiki soon).
and ended up with a working inkscape aqua again. Wow - didnt expect that.
Now I find that some libs are not compiled into the package, which will make the app not so portable. I removed the app from the packaging folder, than crash reporter says this:
Link (dyld) error:
Library not loaded: /opt/local/lib/libgtkmm-2.4.1.dylib Referenced from: /Users/bub/Desktop/Inkscape.app/Contents/ Resources/bin/inkscape-bin Reason: image not found
AFAIK somebody commented the instructions on compiling some components into the app bundle - can anybody tell me where I do have to look for the lines in question?
BTW.: The new build looks quite promising - it can handle several open documents (the former couldnt), selects files to open much quicker than the former, and didnt crash one single time up to now. Obviously some really good work was done behind the scenes inbetween - thanks a lot to people in charge.
Greetings,
Wolf
On 11/2/10 15:04, Wolf Drechsel wrote:
Now I find that some libs are not compiled into the package, which will make the app not so portable. I removed the app from the packaging folder, than crash reporter says this:
Link (dyld) error:
Library not loaded: /opt/local/lib/libgtkmm-2.4.1.dylib Referenced from: /Users/bub/Desktop/Inkscape.app/Contents/ Resources/bin/inkscape-bin Reason: image not found
AFAIK somebody commented the instructions on compiling some components into the app bundle - can anybody tell me where I do have to look for the lines in question?
Did you uncomment line 33 in 'Contents/Resources/bin/inkscape'
# export DYLD_LIBRARY_PATH="$TOP/lib"
as told by 'osx-build.sh' after creating the bundle?
Note: this is based on my assumption that rewriting the install_names of the bundled shared dynamic libraries does not work in your case because iirc you use the default prefix '/opt/local' for the MacPorts tree (which is too short to allow for some of the resulting relative '@executable_path/..' library install names).
~suv
participants (3)
-
Jon Cruz -
Wolf Drechsel -
~suv