More problems with 1.9.2

[ratkins]

The files:

wx/accessors.rb
wx/keyword_ctors.rb
wx/keyword_defs.rb

do not exist in the tarball:

% pwd
/home/rwa/Distributions/test/wxruby-1.9.2
% find . -name accessors.rb
%

but are required in wx.rb:

% tail wx.rb
Dir.glob(class_files) do | class_file |
require ‘wx/classes/’ + class_file[/\w+.rb$/]
end

Load in syntax sweetner

require ‘wx/accessors’
require ‘wx/keyword_ctors’
require ‘wx/keyword_defs’

These files do appear in the svn sources. If I copy the files from the
svn
sources, I can now run the examples.

Unfortunately, I’ve done too much mucking around to know exactly where
the
segfault issue went away. Grr.

[ratkins]

Robert A. wrote:

The files:

wx/accessors.rb
wx/keyword_ctors.rb
wx/keyword_defs.rb

do not exist in the tarball:

Yes, sorry. 90+% of our distribution is binary gems which the developers
build from SVN, and we messed up with the tarball in 1.9.2. The script
that builds the tarball is already fixed in SVN, but thanks for the
report.

Unfortunately, I’ve done too much mucking around to know exactly where
the segfault issue went away. Grr.
Maybe there was a stale source created by SWIG 1.3.33 kicking around.
I’ve just tried building HEAD + SWIG 1.3.33 + gcc + Wx 2.8.7 unicode and
it builds but will segfault early on loading the first Wx class/module,
with a poss bad value for the tracking hash.

If the segfault issue is resolved, can I check you’ve now got a working
1.9.2 built with SWIG 1.3.31?

I’ll look into the gcc build error on Linux in URLDataObject.cpp when I
have access to a machine next week. What gcc version is on your distro
please?

thanks again
alex

[ratkins]

On Dec 27, 2007 5:43 PM, Alex F. [email protected] wrote:

Yes, sorry. 90+% of our distribution is binary gems which the developers
If the segfault issue is resolved, can I check you’ve now got a working
1.9.2 built with SWIG 1.3.31?

Correct. I had to do some more mucking around related to
wxUSE_MEDIACTRL in
the wx configuration - it was off by default and didn’t seem to respect
the
configuration flag --enable-mediactrl as it was supposed to. I went in
and
hardwired the setting to turn that on and it corrected some undefined
preprocessor symbol issues.

I’ll look into the gcc build error on Linux in URLDataObject.cpp when I
have access to a machine next week. What gcc version is on your distro
please?

% gcc --version
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-59)

As for the values of wx-config --libs std, stc , once I rebuilt with
monolithic I was seeing the full paths, and didn’t want to go back and
reconfigure and build to verify the old problem. Sorry.

Thanks for your help.

[ratkins]

Robert A. wrote:

I had to do some more mucking around related to wxUSE_MEDIACTRL in the
wx configuration - it was off by default and didn’t seem to respect
the configuration flag --enable-mediactrl as it was supposed to. I
went in and hardwired the setting to turn that on and it corrected
some undefined preprocessor symbol issues.
On Windows and OS X, --enable-mediactrl is enough because there’s a
system media player (Windows Media/Quicktime). On Linux it requires
Gstreamer and a bunch of other libraries. The ones I had to install are
listed on the HowToBuildWxWidgets wiki page, but this will vary by
distro. The reliable (if painful) way is to repeatedly run wxWidgets’s
configure with --enable-mediactrl, then look at the detail of config.log
to see why wxMediaCtrl was skipped (which library was missing).

Anyway, I think to avoid making the 1.9.3 build too taxing on Linux
(Wx::MediaCtrl is only in SVN) we’ll make wxRuby detect if wxWidgets
supports MediaCtrl, and skip that class if not. Unfortunately it’s
fiddly b/c the preprocessor symbols aren’t available to Rake, but I have
a workaround to check in.

Thanks for all the feedback
alex