Packaging wxRuby fails

dubstep · March 9, 2011, 4:44pm

Hi there,

I (once again) just compiled wxRuby 2.0.1 successfully, but I can’t get
“rake gem” to work:

===========================================
$ rake gem
(in /home/quintus/Downloads/wxruby-2.0.1)
Enabling DYNAMIC build
Enabling RELEASE build
Enabling UNICODE build
The following wxWidgets features are not available and will be skipped:
PrinterDC
rake aborted!
undefined method `write' for #<Syck::Emitter:0x0000000303dba0> /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in`end_document’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in
`visit_Psych_Nodes_Document' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/visitor.rb:10:in`accept’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in
`block in visit_Psych_Nodes_Stream' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in`each’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in
`visit_Psych_Nodes_Stream' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/visitor.rb:11:in`accept’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/nodes/node.rb:36:in
`to_yaml' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych.rb:166:in`dump’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/core_ext.rb:13:in
`psych_to_yaml' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:715:in`node_export’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:715:in
`add' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:715:in`encode_with’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:737:in
`block (2 levels) in to_yaml' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:736:in`map’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:736:in
`block in to_yaml' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/syck.rb:401:in`call’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/syck.rb:401:in `emit' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/syck.rb:401:in`quick_emit’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:735:in
`to_yaml' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:78:in`block (2 levels) in write_package’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:73:in
`block (3 levels) in add_gem_contents' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:83:in`new’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:67:in
`block (2 levels) in add_gem_contents' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in`wrap’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in
`block in add_gem_contents' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:113:in`add_file’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:63:in
`add_gem_contents' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:31:in`open’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package.rb:68:in
`open' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:77:in`block in write_package’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:76:in
`open' /opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:76:in`write_package’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:39:in
`build' /home/quintus/Downloads/wxruby-2.0.1/rake/rakepackage.rb:68:in`block in
create_gem_tasks’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:634:in `call' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:634:in`block in
execute’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:629:in `each' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:629:in`execute’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:595:in `block in invoke_with_call_chain' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/monitor.rb:201:in`mon_synchronize’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:588:in
`invoke_with_call_chain' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:581:in`invoke’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2041:in `invoke_task' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2019:in`block (2
levels) in top_level’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2019:in `each' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2019:in`block in
top_level’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2058:in
`standard_exception_handling' /opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2013:in`top_level’
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:1992:in `run' /opt/rubies/ruby-1.9.2-p180/bin/rake:31:in`’

It seems the Rakefiles are mixing up Psych with Syck. What’s happening
here? And how do I get a gem file?

Valete,
Marvin

quintus · March 12, 2011, 11:22pm

Hi Marvin,

2011/3/9 Quintus [email protected]:

Hi there,

I (once again) just compiled wxRuby 2.0.1 successfully, but I can’t get
“rake gem” to work:

Are you on Ubuntu / Linux ?
If so, may be the following page from the wiki will help :
http://wxruby.rubyforge.org/wiki/wiki.pl?BuildingForUbuntu

Cheers,
Chauk-Mean

quintus · March 13, 2011, 8:38am

Am 12.03.2011 23:07, schrieb Chauk-Mean P.:

http://wxruby.rubyforge.org/wiki/wiki.pl?BuildingForUbuntu

Nope, I’m running Arch Linux. And the actual building of wxRuby went
well, I end up with wxruby2.so, but the command to build the gem, which
doesn’t do any compiling anymore but is just supposed to grab all
necessary files and put them into the gem file, fails. “rake” (without
arguments) works fine, but then “rake gem” fails.

In the meantime I’ve solved the problem by buiding a second Ruby without
Psych support–all went well and I got my gem, but sadly it segfaults. I
suspect it’s that incredible libcairo/libpixman error I’ve been
expierencing so many times now, and if wxRuby hadn’t been my favourite
GUI toolkit for such a long time, I wouldn’t hesitate to look for a new
one. The minimal sample runs without problems, but any other more
complex thing crashes. Here’s the output of running bigdemo.rb:

=====================================================================
$ ruby bigdemo.rb

(wxruby:2222): Gtk-WARNING **: Error parsing gtk-icon-sizes string:
‘panel-menu=24,24
panel=20,20
gtk-button=18,18
gtk-large-toolbar=24,24’
bigdemo.rb:345: [BUG] Segmentation fault
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]

– control frame ----------
c:0010 p:---- s:0047 b:0047 l:000046 d:000046 CFUNC :set_active_target
c:0009 p:1359 s:0043 b:0043 l:000c68 d:000c68 METHOD bigdemo.rb:345
c:0008 p:---- s:0024 b:0024 l:000023 d:000023 FINISH
c:0007 p:---- s:0022 b:0022 l:000021 d:000021 CFUNC :new
c:0006 p:0047 s:0016 b:0016 l:000015 d:000015 METHOD bigdemo.rb:814
c:0005 p:---- s:0012 b:0012 l:000011 d:000011 FINISH
c:0004 p:---- s:0010 b:0010 l:000009 d:000009 CFUNC :main_loop
c:0003 p:0300 s:0007 b:0007 l:000ba8 d:002360 EVAL bigdemo.rb:823
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:000ba8 d:000ba8 TOP

– Ruby level backtrace information

bigdemo.rb:823:in <main>' bigdemo.rb:823:in main_loop’
bigdemo.rb:814:in on_init' bigdemo.rb:814:in new’
bigdemo.rb:345:in initialize' bigdemo.rb:345:in set_active_target’

– C level backtrace information

/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_vm_bugreport+0x5f)
[0x7f199b9e135f]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x62b04)
[0x7f199b8c0b04]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_bug+0xb3)
[0x7f199b8c1a33]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x116715)
[0x7f199b974715]
/lib/libpthread.so.0(+0xf150) [0x7f199b650150]
/usr/lib/libpixman-1.so.0(pixman_image_composite32+0x400)
[0x7f198f15a000]
/usr/lib/libcairo.so.2(+0x3a31c) [0x7f1992bbc31c]
/usr/lib/libcairo.so.2(+0x6480c) [0x7f1992be680c]
/usr/lib/libcairo.so.2(+0x65cac) [0x7f1992be7cac]
/usr/lib/libcairo.so.2(+0x4848b) [0x7f1992bca48b]
/usr/lib/libcairo.so.2(+0x4b000) [0x7f1992bcd000]
/usr/lib/libcairo.so.2(+0x4a123) [0x7f1992bcc123]
/usr/lib/libcairo.so.2(+0x4ac02) [0x7f1992bccc02]
/usr/lib/libcairo.so.2(+0x4b9d1) [0x7f1992bcd9d1]
/usr/lib/libcairo.so.2(+0x48073) [0x7f1992bca073]
/usr/lib/libcairo.so.2(+0x216ed) [0x7f1992ba36ed]
/usr/lib/libcairo.so.2(cairo_fill_preserve+0x20) [0x7f1992b9a2e0]
/usr/lib/libcairo.so.2(cairo_fill+0x9) [0x7f1992b9a2f9]
/usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so(+0x14a5e)
[0x7f198d472a5e]
/usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so(+0x18fa9)
[0x7f198d476fa9]
/usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so(+0x947f)
[0x7f198d46747f]
/usr/lib/libgtk-x11-2.0.so.0(+0x8d01b) [0x7f1996dc401b]
/usr/lib/libgtk-x11-2.0.so.0(+0x8d24f) [0x7f1996dc424f]
/usr/lib/libgtk-x11-2.0.so.0(+0x1363a8) [0x7f1996e6d3a8]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9) [0x7f1996844e09]
/usr/lib/libgobject-2.0.so.0(+0x1f618) [0x7f1996856618]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x625)
[0x7f199685f9e5]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7f199685fe13]
/usr/lib/libgtk-x11-2.0.so.0(+0x25181f) [0x7f1996f8881f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_container_propagate_expose+0x1c6)
[0x7f1996defc96]
/usr/lib/libgtk-x11-2.0.so.0(+0x8399b) [0x7f1996dba99b]
/usr/lib/libgtk-x11-2.0.so.0(+0xb7804) [0x7f1996dee804]
/usr/lib/libgtk-x11-2.0.so.0(+0x1363a8) [0x7f1996e6d3a8]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9) [0x7f1996844e09]
/usr/lib/libgobject-2.0.so.0(+0x1f618) [0x7f1996856618]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x625)
[0x7f199685f9e5]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7f199685fe13]
/usr/lib/libgtk-x11-2.0.so.0(+0x25181f) [0x7f1996f8881f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_container_propagate_expose+0x1c6)
[0x7f1996defc96]
/usr/lib/libgtk-x11-2.0.so.0(+0x8399b) [0x7f1996dba99b]
/usr/lib/libgtk-x11-2.0.so.0(+0xb7804) [0x7f1996dee804]
/usr/lib/libgtk-x11-2.0.so.0(+0x1363a8) [0x7f1996e6d3a8]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9) [0x7f1996844e09]
/usr/lib/libgobject-2.0.so.0(+0x1f618) [0x7f1996856618]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x625)
[0x7f199685f9e5]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7f199685fe13]
/usr/lib/libgtk-x11-2.0.so.0(+0x25181f) [0x7f1996f8881f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_container_propagate_expose+0x1c6)
[0x7f1996defc96]
/usr/lib/libgtk-x11-2.0.so.0(+0xb7804) [0x7f1996dee804]
/usr/lib/libgtk-x11-2.0.so.0(+0x1363a8) [0x7f1996e6d3a8]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x15e) [0x7f1996844ebe]
/usr/lib/libgobject-2.0.so.0(+0x1f618) [0x7f1996856618]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x625)
[0x7f199685f9e5]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7f199685fe13]
/usr/lib/libgtk-x11-2.0.so.0(+0x25181f) [0x7f1996f8881f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x58a) [0x7f1996e6bbca]
/usr/lib/libgdk-x11-2.0.so.0(+0x42cf2) [0x7f1996ac8cf2]
/usr/lib/libgdk-x11-2.0.so.0(+0x3dc1b) [0x7f1996ac3c1b]
/usr/lib/libgdk-x11-2.0.so.0(gdk_window_process_all_updates+0x129)
[0x7f1996ac5e39]
/usr/lib/libgtk-x11-2.0.so.0(+0xb74b1) [0x7f1996dee4b1]
/usr/lib/libgdk-x11-2.0.so.0(+0x1d366) [0x7f1996aa3366]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f3)
[0x7f199628cbf3]
/usr/lib/libglib-2.0.so.0(+0x423d0) [0x7f199628d3d0]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x182) [0x7f199628da42]
/usr/lib/libgtk-x11-2.0.so.0(gtk_dialog_run+0x19b) [0x7f1996df174b]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN15wxMessageDialog9ShowModalEv+0x4a)
[0x7f1997e30bca]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_Z12wxMessageBoxRK8wxStringS1_lP8wxWindowii+0x4e)
[0x7f1997dad02e]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN8wxLogGui5FlushEv+0x279)
[0x7f1997edabe9]
/usr/lib/libwx_baseu-2.8.so.0(ZN5wxLog15SetActiveTargetEPS+0x27)
[0x7f199792c867]
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1/gems/wxruby-ruby19-2.0.1-x86_64-linux/lib/wxruby2.so(+0x45ccb8)
[0x7f1999b02cb8]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17d206)
[0x7f199b9db206]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x172d8e)
[0x7f199b9d0d8e]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x1791ab)
[0x7f199b9d71ab]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17a488)
[0x7f199b9d8488]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_class_new_instance+0x30)
[0x7f199b911b70]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17d206)
[0x7f199b9db206]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x172d8e)
[0x7f199b9d0d8e]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x1791ab)
[0x7f199b9d71ab]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17a488)
[0x7f199b9d8488]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_funcall+0xba)
[0x7f199b9d90ea]
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1/gems/wxruby-ruby19-2.0.1-x86_64-linux/lib/wxruby2.so(_ZN9wxRubyApp6OnInitEv+0x5c)
[0x7f19998b808c]
/usr/lib/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPw+0x54) [0x7f1997920c64]
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1/gems/wxruby-ruby19-2.0.1-x86_64-linux/lib/wxruby2.so(+0x20f060)
[0x7f19998b5060]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17d206)
[0x7f199b9db206]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x172d8e)
[0x7f199b9d0d8e]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x1791ab)
[0x7f199b9d71ab]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_iseq_eval_main+0xb1)
[0x7f199b9dc6a1]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x68eba)
[0x7f199b8c6eba]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(ruby_exec_node+0x1d)
[0x7f199b8c7e1d]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(ruby_run_node+0x1e)
[0x7f199b8ca08e]
ruby(main+0x4b) [0x40099b]
/lib/libc.so.6(__libc_start_main+0xfd) [0x7f199aa38dcd]
ruby() [0x400889]

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension
libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

This is my libpixman:

=====================================================================
$ LANG=EN_US pacman -Qi pixman
Name : pixman
Version : 0.20.2-1
URL : http://xorg.freedesktop.org
Licenses : custom
Groups : None
Provides : None
Depends On : glibc
Optional Deps : None
Required By : cairo lib32-pixman xorg-server
Conflicts With : None
Replaces : None
Installed Size : 528.00 K
Packager : Jan de Groot [email protected]
Architecture : x86_64
Build Date : Wed Jan 19 15:45:12 2011
Install Date : Sat Jan 22 14:50:33 2011
Install Reason : Installed as a dependency for another package
Install Script : No
Description : Pixman library

Btw. this was the reason why I wanted to compile wxRuby myself. But
appearently it didn’t help.

Vale,
Marvin

quintus · March 16, 2011, 11:09pm

Am 16.03.2011 21:56, schrieb Chauk-Mean P.:

necessary files and put them into the gem file, fails. “rake” (without
arguments) works fine, but then “rake gem” fails.

That’s strange.
What options did you use for building ruby-1.9.2-p180 ?

$ ./configure --prefix=/opt/rubies/ruby-1.9.2-p180 --enable-shared
CFLAGS=-I/usr/src/linux-2.6.37-ARCH/include
$ make
$ sudo make install

I have to provide the extra CFLAGS, because on Arch recently some header
files in /usr/inclide/asm-generic/ disappeared and made Ruby fail to
compile when it came to socket (which I need). The files are present in
the bare kernel header directory, so I put that into CFLAGS.

Do you use the built-in rubygems or have you upgraded rubygems ?

I upgraded via gem update --system. At the moment I’m running:

$ gem env
RubyGems Environment:

RUBYGEMS VERSION: 1.6.2
RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-linux]
INSTALLATION DIRECTORY:
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1
RUBY EXECUTABLE: /opt/rubies/ruby-1.9.2-p180/bin/ruby
EXECUTABLE DIRECTORY: /opt/rubies/ruby-1.9.2-p180/bin
RUBYGEMS PLATFORMS:
- ruby
- x86_64-linux
GEM PATHS:
- /opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1
- /home/quintus/.gem/ruby/1.9.1
GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- “install” => “–format-executable”
- “update” => “–format-executable”
- “rdoc” => “–format=hanna”
REMOTE SOURCES:
- http://rubygems.org/

FWIW, you can also install wxRuby without creating the gem via :
rake install.

As I already said, I compiled a Ruby without Psych support (by deleting
the psych extension’s directory from the Ruby sources prior to the
building commands), then I recompiled wxRuby with
$ rake
$ rake gem
and got the gem file. I took it and installed it onto the Ruby with
Psych support–works fine. However, I don’t want to have an extra Ruby
installation solely for building wxRuby. Which then segfaults.

If I remember correctly, in Rails one can force the YAML engine to Syck
like this:

YAML::Engine.default_yamler = Syck

I’m not sure wheather this is rails-specific or not (can’t try today),
but if not including this line in the main Rakefile should be a possible
workaround.

Vale,
Quintus

quintus · March 16, 2011, 9:59pm

Hi Marvin,

2011/3/13 Quintus [email protected]:

Are you on Ubuntu / Linux ?
If so, may be the following page from the wiki will help :
http://wxruby.rubyforge.org/wiki/wiki.pl?BuildingForUbuntu

Nope, I’m running Arch Linux. And the actual building of wxRuby went
well, I end up with wxruby2.so, but the command to build the gem, which
doesn’t do any compiling anymore but is just supposed to grab all
necessary files and put them into the gem file, fails. “rake” (without
arguments) works fine, but then “rake gem” fails.

That’s strange.
What options did you use for building ruby-1.9.2-p180 ?
Do you use the built-in rubygems or have you upgraded rubygems ?

FWIW, you can also install wxRuby without creating the gem via :
rake install.

Cheers,
Chauk-Mean.

quintus · March 17, 2011, 9:55am

Am 16.03.2011 22:45, schrieb Quintus:

If I remember correctly, in Rails one can force the YAML engine to Syck
like this:

YAML::Engine.default_yamler = Syck

I’m not sure wheather this is rails-specific or not (can’t try today),
but if not including this line in the main Rakefile should be a possible
workaround.

It’s not specific to Rails and works like this:

require “yaml”
YAML::ENGINE.yamler = “syck”

Note the uppercase ENGINE and the “syck” string. However, adding it to
the top of wxRuby’s Rakefile didn’t do the trick, I’m still getting the
same error.

Vale,
Marvin

quintus · March 22, 2011, 10:27pm

Am 17.03.2011 09:20, schrieb Quintus:

It’s not specific to Rails and works like this:

Regarding the pixman segfault I can now narrow this down between three
versions of libpixman. I just downgraded my pixman lib to 0.20.0,
leaving everything else on my system untouched and I got wxRuby working
again. Previously installed was 0.20.2, so somewhere between those
versions there must be something wrong with libpixman. Tomorrow I’m
going to file a bug on the Arch tracker, and hopfully I’ll get some
informative input there because pinning pixman to 0.20.0 is not a real
solution I think (first I’ll try to get a hold on pixman 0.20.1, but
getting Arch packages for versions out of date that are not cached on
your system is kinda difficult). Btw. what’s with Ubuntu? Does it work
there at the moment?

Valete,
Marvin

quintus · March 24, 2011, 1:06am

This isn’t so much a wxRuby issue, as it is a wxWidgets issue.
Specifically, the version we use with wxRuby. Newer versions I believe
does not have this issue. But the main issue that happens, is that the
change between 0.20.0 and 0.20.2, is that pixman_image_composite32()
changed
the function signature from what wxWidgets is expecting, and what pixman
is
expecting. I tracked this problem down, specifically to that issue, and
difference in signatures. Sadly, I haven’t been able to get newer
versions
of wxWidgets to work with wxRuby 2.0.1, and I haven’t been working on
wxRuby
as of lately, as I’ve been having issues in Real Life to deal with.
Hence
for the lateness in the conversation. Basically, what is happening, is
Ruby
is catching the C/C++ Side of the system error, that attempts to access
invalid memory, when pixman_image_composite32() attempts to access a
memory
location, that is not valid. I believe that the previous method
signature
in question, had an integer at the position of question, where it’s now
expecting a memory address.

Again, sadly, I don’t remember all of the specifics, and I know it is an
issue with the older version of wxWidgets that is being used, that is at
fault. Not wxRuby. I apologize for the lateness in this reply, and
hope
this helps you to track down the problem, or find a way for wxRuby 2.0.1
to
compile against a newer version of wxWidgets.

hth,

Mario

quintus · March 23, 2011, 4:18pm

Am 22.03.2011 21:17, schrieb Quintus:

getting Arch packages for versions out of date that are not cached on
your system is kinda difficult). Btw. what’s with Ubuntu? Does it work
there at the moment?

Valete,
Marvin

Just thinking that the Arch tracker is not the correct place to file
this bug–it’s not in Arch, it’s in cairo/pixman. However, filing a bug
“pixman 0.20.2 breaks wxRuby and segfaults” on bugs.freedesktop.org
doesn’t seem an adequate information for the pixman developers (btw.
there has never been a 0.20.1 version of pixman, so the change breaking
wxRuby happened between the 0.20.0 release and the 0.20.2 one). As I’m
not familiar with wxRuby’s internals I cannot be of much help on
tracking down the problem–I don’t even know if it’s really a pixman
problem or a wxRuby one.

Suggestions?

Valete,
Marvin

quintus · April 2, 2011, 1:48am

Hi Marvin and Mario, I’m coming up against the same issue and have done
some investigation too.

(I previously sent a message about this to wxruby-developers but I don’t
think that was the right list. Sorry about that.)

I’m not sure that Mario’s assessment of it being a wxWidgets issue is
right, because on systems that show the problem, the wxWidgets sample
apps work fine but wxruby fails.

After reading Mario’s message I tried to compile wxRuby with the latest
development version, but the number of code changes to wxWidgets was too
great and I couldn’t get it to compile. Mario, do you know of a
wxWidgets version that allows wxRuby to work?

I have managed to get wxRuby up and running on Ubuntu by modifying
pixman. I got this insight by debugging the crash with gdb.

In the file pixman/pixman.c, function “lookup_composite_function”, I
ifdef-ed out the following code:

for (i = 0; i < N_CACHED_FAST_PATHS; ++i)
{
const pixman_fast_path_t *info = &(cache->cache[i].fast_path);

/* Note that we check for equality here, not whether
 * the cached fast path matches. This is to prevent
 * us from selecting an overly general fast path
 * when a more specific one would work.
 */
if (info->op == op            &&
    info->src_format == src_format    &&
    info->mask_format == mask_format    &&
    info->dest_format == dest_format    &&
    info->src_flags == src_flags    &&
    info->mask_flags == mask_flags    &&
    info->dest_flags == dest_flags    &&
    info->func)
{
    *out_imp = cache->cache[i].imp;
    *out_func = cache->cache[i].fast_path.func;

    goto update_cache;
}

}

And then wxruby works. So it looks like disabling the “fast path
caching” feature of pixman fixes the bug.

If you want to try it, download the pixman source, modify the file, then
compile and install pixman. Rebuild wxWidgets and wxRuby, and then you
should have a working wxRuby.

I don’t know where to go next to get a proper resolution to this
problem. As I said, because the wxWidgets sample works, and apps such as
the Ubuntu GUI work otherwise with their use of pixman, I’m thinking it
must be some particular way that wxRuby interacts with wxWidgets that
causes the problem. Can anyone suggest a next step?

Thanks,
David

quintus · March 26, 2011, 12:10am

Am 24.03.2011 00:11, schrieb Mario S.:

is catching the C/C++ Side of the system error, that attempts to access

hth,

Mario

Not sure why my mail didn’t make it to the list, but I’ll try again.

First, thanks for your answer. If it’s not a wxRuby issue, there’s some
hope to get the whole thing resolved. I really do like the wxRuby GUI
toolkit, and unless I’m forced to I wouldn’t like to change it.
But before further developing, solve the Real Life problems. Although
Open-Source software is a great way to spend time, tough.

I’ve just started learning C++ one week ago, and when I’ve gathered some
experience, I’ll take a look at the wxRuby code and hopefully get it to
compile with newer wxWidgets versons. I’m however not familiar with SVN
(always used Git until now), but that can be worked out either.

Vale,
Marvin

quintus · April 10, 2011, 3:38am

Thanks for your response Marvin, sorry it took a while, I forgot to
subscribe to the list.

Those were good suggestions, I didn’t think of those. About SWIG –
since the version in stable supports newer swig versions I tried
compiling and installing that, but I got the same issue. So nothing in
the newer swig fixes the issue.

I installed wxpython with apt-get and was able to run a sample app with
no issues. So the problem doesn’t seem to affect wxpython.

I definitely agree this isn’t a solution for users. I’m thinking I’ll
have to annoy the pixman team. I just reproduced the problem on the
recent pixman 0.21.6 release.

For anyone wanting to help, you can test your theories quickly by
compiling the modified pixman and installing into /usr/local. As long as
/usr/local/lib is on your dynamic lib path then you can switch back and
forth by renaming the pixman libs in /usr/local/lib to hide them. The
standard pixman libs in /usr/lib should be loaded when nothing’s found
in /usr/local/lib.

I’ll let you know how I get on.

quintus · April 2, 2011, 10:32am

Am 02.04.2011 01:48, schrieb David B.:

I don’t know where to go next to get a proper resolution to this
problem. As I said, because the wxWidgets sample works, and apps such as
the Ubuntu GUI work otherwise with their use of pixman, I’m thinking it
must be some particular way that wxRuby interacts with wxWidgets that
causes the problem. Can anyone suggest a next step?

If it wasn’t only wxRuby not working (which is not really related to
pixman), I’d file a bug against pixman. What about other wxWidgets
bindings, such as e.g. wxpython? Do they face the same problems? If not,
maybe the outdated version of SWIG used by wxRuby is in fault
(disclaimer: I never used SWIG)?

A “proper resultion” however can’t be achieved by telling wxRuby users
“oh, and you have to patch pixman, recompile it, wxWidgets and wxRuby”.
If the pixman team doesn’t want to reenable their code again, we’re
kinda stuck. I don’t know what to do either, but if I can be of any
help… You know. For the moment, I’ll just continue learning C++.

Vale,
Marvin

quintus · April 10, 2011, 4:00am

I thought I’d start at Ubuntu and reported a bug here:

quintus · April 12, 2011, 2:56pm

Thanks for your help Marvin, I’ve done that

quintus · April 10, 2011, 10:38am

Am 10.04.2011 04:00, schrieb David B.:

I thought I’d start at Ubuntu and reported a bug here:

Bug #756237 “wxRuby crashes with segmentation fault in pixman_im...” : Bugs : pixman package : Ubuntu

Thanks, lets see where we get…

In your bug report you suggest to install the wxRuby gem for 1.8 rather
than that one for 1.9, maybe you can correct this? I posted a comment
about it, but I think I can’t update the original bug report.

Vale,
Marvin

quintus · May 9, 2011, 10:31pm

On 09/05/11 17:36, Quintus wrote:

Some progress seems to have been made, but wxRuby still doesn’t run on
any Ubuntu> Lucid. The bug at
Bug #632984 “libwx_gtk2u_media-2.8.so.0 missing from libwxgtk2.8...” : Bugs : wxwidgets2.8 package : Ubuntu has
finally been fixed (for Oneiric), just to reveal another one (see my
last comment on that bug) that still prevents the main bug at
Bug #756237 “wxRuby crashes with segmentation fault in pixman_im...” : Bugs : pixman package : Ubuntu to get
flagged for Natty.

thanks for the update - and thanks also for reporting on and documenting
the issues on the Ubuntu bugtracker. I was half-thinking of switching to
Fedora anyway before the next Ubuntu came out - maybe this will tip me
over.

best
alex

quintus · May 9, 2011, 6:46pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 12.04.2011 14:33, schrieb David B.:

Thanks, lets see where we get…

In your bug report you suggest to install the wxRuby gem for 1.8 rather
than that one for 1.9, maybe you can correct this? I posted a comment
about it, but I think I can’t update the original bug report.

Vale,
Marvin

Some progress seems to have been made, but wxRuby still doesn’t run on
any Ubuntu > Lucid. The bug at
Bug #632984 “libwx_gtk2u_media-2.8.so.0 missing from libwxgtk2.8...” : Bugs : wxwidgets2.8 package : Ubuntu has
finally been fixed (for Oneiric), just to reveal another one (see my
last comment on that bug) that still prevents the main bug at
Bug #756237 “wxRuby crashes with segmentation fault in pixman_im...” : Bugs : pixman package : Ubuntu to get
flagged for Natty.

Semms fate is against wxRuby at the moment

Valete,
Marvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNyBfiAAoJELh1XLHFkqhas2IIAJDxyG7GRxxNPokfuVlqB214
Ocmkt6fod9Q89i+FDtNSUN/+FmoF9O0aNXAf+SURtot0PO8/PF2swnyiL1QiUd2C
sByJGK4U3mjJC0GkvIR1OqKulm7nsxU8LGuMpdZDbEco0MU42R6FmguLMMeBU8uG
Y1rOWhKC2rkf8znOMoiwU8j6Z4A2UbxMPoK4u7BZu2otDFcUSu1A7UBO/HvisBxE
2y1BKclxV/uFiVoYeiGTKZQBRt58zxuJOdtnqVQtEbw0XjM6KzvoRXgtbTcUU1zc
Gd4LoXtET6etDQ/q0vrc3arCyLLdW4z3bUJno1YLmnQmpK3ck2gV6NqR8xmRg5A=
=98fJ
-----END PGP SIGNATURE-----

quintus · May 10, 2011, 4:18am

On Mon, May 9, 2011 at 9:36 AM, Quintus [email protected] wrote:

Marvin

Martin, I have been quite successful at deploying both 32 bit and 64-bit
10.04 installations of wxRuby. I had to go back to the 2.0.0 gem for 64,
but
it seems to work quite fine with our rather elaborate application.

quintus · May 10, 2011, 8:24am

Here’s the bug that discussion references, in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613221

Packaging wxRuby fails

– Ruby level backtrace information

– C level backtrace information

[NOTE] You may have encountered a bug in the Ruby interpreter or extension libraries. Bug reports are welcome. For details: http://www.ruby-lang.org/bugreport.html

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension
libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html