After decoding the unresolved symbols from wxruby2.so using c++filt, and
comparing with the symbols provided by wxGTK, it became clear that wxGTK
was
using wchar_t whereas wxruby2.so was using char. So I rebuilt wxGTK,
turning off unicode. That worked. No more unresolved symbols. What
gives? Should the wxruby code have been built using wchar_t, and if so,
how?
the crash is in rb_hash_aref. I saw that I was not the only one to run
into
this from recent mailing list discussion.
The issue appears to be that swig_ruby_trackings has a bogus value. In
my
case it always happens to be 4. It appears it is supposed to point to
valid
storage.
where swig_ruby_trackings is looked up, and if it comes back nil, a new
one
is created. Except that, for reasons I don’t understand, it comes back
4,
not 0. When this gets dereferenced after a series of calls from
Init_wxRubyConstants, segfault. Any help? This seems like a real bug,
and
I’m starting to wonder if this package is usable at all.
So I rebuilt wxGTK, turning off unicode. That worked. No more
unresolved symbols. What gives? Should the wxruby code have been
built using wchar_t, and if so, how?
I’m sorry but I don’t understand this. Unfortunately I’m away and don’t
have a Linux box here - but, wxruby2 should only work with a unicode
build; all of the conversions from wxString to ruby Strings assume that
wxGTK has been built with unicode support.
However, now I get the following:
the crash is in rb_hash_aref. I saw that I was not the only one to
run into this from recent mailing list discussion.
Could you refer me the discussion please?
The issue appears to be that swig_ruby_trackings has a bogus value.
In my case it always happens to be 4. It appears it is supposed to
point to valid storage.
The relevant function appears to be this one:
SWIGRUNTIME void SWIG_RubyInitializeTrackings(void)
This is code that’s generated by SWIG, not immediately part of wxRuby.
What version of SWIG are you using? (swig -version) The most recently
released version of SWIG came out after wxRuby 1.9.2 in November and
hasn’t yet been tested with it. I’d strongly suggest using version
1.3.31 for now.
This seems like a real bug, and I’m starting to wonder if this package
is usable at all.
Clearly not for you, clearly yes for lots of other people. There’s
something that’s different about your environment that’s causes serious
bugs; let’s figure out what it is.
So I rebuilt wxGTK, turning off unicode. That worked. No more
unresolved symbols. What gives? Should the wxruby code have been
built using wchar_t, and if so, how?
I’m sorry but I don’t understand this. Unfortunately I’m away and don’t
have a Linux box here - but, wxruby2 should only work with a unicode
build; all of the conversions from wxString to ruby Strings assume that
wxGTK has been built with unicode support.
Somehow my build is configured otherwise. I don’t understand the
mechanisms
for how this is configure, so I don’t know how it got out of whack.
What version of SWIG are you using? (swig -version) The most recently
released version of SWIG came out after wxRuby 1.9.2 in November and
hasn’t yet been tested with it. I’d strongly suggest using version
1.3.31 for now.
Yes, definitely, to 1.3.31 please. SWIG versions are notoriously
incompatible even between minor versions, and wxRuby hincludesas
numerous hacks to work around SWIG bugs.
Then you should be able to do
rake reswig && rake
If this improves things I will update the wiki to make it clearer that
there is the specific version dependency