wxruby users - Jul 2005 - Can''t compile the cvs-tree

Hi folks,

Let me start off by saying I''ve just been following wxruby development
for two or three days now and have read up on alot on what has been
going on. I must say I''m impressed and happy about all the things being
developed and created by you guys! You got me all excited and I know
I''m
not the only one. If I have an opportunity to spend more time
investigating Swig and wx I might even be able to help out somewhere I
can..... who knows, I''d like it but like all of you guys I have a busy
schedule :)

Anyway, enough of that. The second reason for this email was that I''m
having difficulty compiling the current source tree. I have done a cvs
update right before writing this email just to be sure.

I am running Gentoo and I have three versions of Wx installed: 2.4.2,
2.5.3 and 2.6.1 all of course compiled for GTK (using emerge) and the
last two are I believe built with unicode support.

In order to switch between versions I simply link my /usr/bin/wx-config
to the approriate config-scripts. The result of this change clearly
shows in the build commands issued.

------snips alot of text-------

While typing this email and writing my initial problem down I noticed
one small difference in Wx source-code of init.cpp and wxruby''s App.i
that I hadn''t noticed before. After two evenings of reading and
learning
wx and wxruby code I found the solution to my compile problem after
fifteen minutes of writing this email.

The incredibly simple fix I made was to swig/classes/App.i on line 16
changed from:
int wxEntry( int argc, char *argv[]);
to:
int wxEntry( int &argc, char *argv[]);

:))  Writing things down in a different environment sometimes makes you
see things you hadn''t noticed before :)
I am really happy atm!

The only thing I don''t understand is why I''m the first here to
experience this. In the end it doesn''t matter.... I hope this helped
someone so far.

------
I waited with finishing and sending this email for the build to
complete. Unfortunately it failed again. I''m really really exhausted
atm
so I''m just gonna lazily post the relevant output without doing some
more digging:

i686-pc-linux-gnu-g++  -c -I/usr/lib/wx/include/gtk-ansi-release-2.5
-I/usr/include/wx-2.5 -DGTK_NO_CHECK_CASTS -D__WXGTK__
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES  -O2 -march=i686  -fPIC   -I
/usr/lib/ruby/site_ruby/1.8 -I /usr/lib/ruby/site_ruby/1.8/i686-linux -I
/usr/lib/ruby/site_ruby -I /usr/lib/ruby/1.8 -I
/usr/lib/ruby/1.8/i686-linux -I . -o obj/Sizer.o src/Sizer.cpp
In file included from src/Sizer.cpp:1092:
src/Sizer.h:25: error: conflicting return type specified for `virtual
   wxSizerItem* SwigDirector_wxSizer::Insert(unsigned int,
wxSizerItem*)''
/usr/include/wx-2.5/wx/sizer.h:324: error:   overriding `virtual void
   wxSizer::Insert(unsigned int, wxSizerItem*)''
src/Sizer.cpp: In member function `virtual wxSizerItem*
   SwigDirector_wxSizer::Insert(unsigned int, wxSizerItem*)'':
src/Sizer.cpp:1163: error: void value not ignored as it ought to be
src/Sizer.cpp: In function `VALUE _wrap_wxSizer_Add__SWIG_0(int, VALUE*,
long
   unsigned int)'':
src/Sizer.cpp:1248: error: cannot convert `arg1->wxSizer::Add(arg2,
arg3, arg4,
   arg5, arg6)'' from type `void'' to type
`wxSizerItem*''
src/Sizer.cpp: In function `VALUE _wrap_wxSizer_Add__SWIG_1(int, VALUE*,
long
   unsigned int)'':

It continues to give ''cannot convert'' errors for all other
methods (I
think, it''s a quite a list).

Maybe I can find some time tommorow to look at this. However I don''t
think this fix will be as easy as the previous :(
-----

I''m looking forward to your reactions.


Thanks for wxruby!

Jonathan Maasland

Jonathan Maasland wrote:
> Hi folks,
> 
> Let me start off by saying I''ve just been following wxruby
development
> for two or three days now and have read up on alot on what has been
> going on. I must say I''m impressed and happy about all the things
being
> developed and created by you guys! You got me all excited and I know
I''m
> not the only one. 
Thanks. Words of support and encouragement are always appreciated.
> I am running Gentoo and I have three versions of Wx installed: 2.4.2,
> 2.5.3 and 2.6.1 all of course compiled for GTK (using emerge) and the
> last two are I believe built with unicode support.
Ok. I''m using 2.5.3 with unicode myself, so that''s the one I
would
recommend you get working first. Based on your report below, I think 
that''s what you''re doing.
> The incredibly simple fix I made was to swig/classes/App.i on line 16
> changed from:
> int wxEntry( int argc, char *argv[]);
> to:
> int wxEntry( int &argc, char *argv[]);
I just checked a simpler fix into CVS: We no longer manually prototype 
wxEntry at all. It''s already declared in wx/init.h so we can just use
that.
> The only thing I don''t understand is why I''m the first
here to
> experience this. In the end it doesn''t matter.... I hope this
helped
> someone so far.
I have no idea why that wasn''t causing problems for me.
> I waited with finishing and sending this email for the build to
> complete. Unfortunately it failed again. I''m really really
exhausted atm
> so I''m just gonna lazily post the relevant output without doing
some
> more digging:
Ok.
> In file included from src/Sizer.cpp:1092:
> src/Sizer.h:25: error: conflicting return type specified for `virtual
>    wxSizerItem* SwigDirector_wxSizer::Insert(unsigned int,
wxSizerItem*)''
> /usr/include/wx-2.5/wx/sizer.h:324: error:   overriding `virtual void
>    wxSizer::Insert(unsigned int, wxSizerItem*)''
> src/Sizer.cpp: In member function `virtual wxSizerItem*
>    SwigDirector_wxSizer::Insert(unsigned int, wxSizerItem*)'':
Hm. Your 2.5.3 sizer.h doesn''t match mine. In mine, all the Insert 
methods return wxSizerItem pointers. Oddly, the 2.5.3 wx docs claim 
those methods return void. [...Researching...]. Ok, the wxWidgets CVS 
tree shows that the DEBIAN_2_5_3_2 tag includes a patch that causes 
wxSizer::Insert to return a wxSizerItem*. The vanilla WX_2_5_3 tag had 
them declared as void returns. Grrrrr.

I''m still trying to figure out how to support different versions of wx 
where they have conflicting API''s. If we put conditionals in the 
swig/classes/include/.h files, then the files in src/ will be 
version-dependent. That may be unavoidable, but I would sure like to 
either minimize it, or embrace it by having multiple src/ directories 
(src/2.5.3/ and src/2.6.1/ etc.). Hm. That''s probably the way to go. 
Comments?

Thanks,

Kevin

Kevin Smith wrote:
> I just checked a simpler fix into CVS: We no longer manually prototype
> wxEntry at all. It''s already declared in wx/init.h so we can just
use
> that.
doh! of course :-)
> Hm. Your 2.5.3 sizer.h doesn''t match mine. In mine, all the Insert
> methods return wxSizerItem pointers. Oddly, the 2.5.3 wx docs claim
> those methods return void. [...Researching...]. Ok, the wxWidgets CVS
> tree shows that the DEBIAN_2_5_3_2 tag includes a patch that causes
> wxSizer::Insert to return a wxSizerItem*. The vanilla WX_2_5_3 tag had
> them declared as void returns. Grrrrr.
>
> I''m still trying to figure out how to support different versions
of wx
> where they have conflicting API''s. If we put conditionals in the
> swig/classes/include/.h files, then the files in src/ will be
> version-dependent. That may be unavoidable, but I would sure like to
> either minimize it, or embrace it by having multiple src/ directories
> (src/2.5.3/ and src/2.6.1/ etc.). Hm. That''s probably the way to
go.
> Comments?
>
> Thanks,
>
> Kevin
hmm.... indeed. This is quite a problem, I looked at the 2.6.1 code and
it''s broken (on multiple places) with 2.5.3. Building wxruby2 against
2.6 fails as well only at a different class now:
----
i686-pc-linux-gnu-g++  -c -I/usr/lib/wx/include/gtk2-ansi-release-2.6
-I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1  -O2
-march=i686  -fPIC   -I /usr/lib/ruby/site_ruby/1.8 -I
/usr/lib/ruby/site_ruby/1.8/i686-linux -I /usr/lib/ruby/site_ruby -I
/usr/lib/ruby/1.8 -I /usr/lib/ruby/1.8/i686-linux -I . -o obj/Icon.o
src/Icon.cpp
src/Icon.cpp: In constructor `SwigDirector_wxIcon::SwigDirector_wxIcon(long
   unsigned int, const wxString&, long int, int, int, bool)'':
src/Icon.cpp:789: error: invalid conversion from `long int'' to
`wxBitmapType''
src/Icon.cpp:789: error:   initializing argument 2 of `wxIcon::wxIcon(const
   wxString&, wxBitmapType, int, int)''
src/Icon.cpp: In function `VALUE _wrap_new_wxIcon(int, VALUE*, long unsigned
   int)'':
src/Icon.cpp:847: error: invalid conversion from `long int'' to
`wxBitmapType''
src/Icon.cpp:847: error:   initializing argument 2 of `wxIcon::wxIcon(const
   wxString&, wxBitmapType, int, int)''
----
It does compile Sizer.i correctly however :))

Is there a specific and compelling reason you want to support the 2.5
release of wx? I think it''d be quite acceptable to require 2.6.1
especially because the 2.5 series is considered a development-branch.
(see http://www.wxwidgets.org/roadmap.htm )
It would simplify matters greatly.

If it''s a matter of package availability, well we could always try to
create and distribute the needed ones ourselves (just a thought).

Thanks,
Jonathan

I hate to reply to myself but I just thought I''d update a bit on the
compilation status.
I removed Icon.(cpp h i) and the build finished succesfully. However
running the samples gives me an ugly segmentation fault without any
meaningful message or reason:
----
ruby -I lib/ samples/controls/controls.rb
lib/wxruby2.so: [BUG] Segmentation fault
ruby 1.8.2 (2004-12-25) [i686-linux]

Aborted
----
Is there a way to set a debug flag or such so I can find out why and
where it failed?

Thanks again,
Jonathan

Jonathan Maasland wrote:
>Kevin Smith wrote:
>
>  
>
>>I just checked a simpler fix into CVS: We no longer manually prototype
>>wxEntry at all. It''s already declared in wx/init.h so we can
just use
>>that.
>>    
>>
>
>doh! of course :-)
>
>  
>
>>Hm. Your 2.5.3 sizer.h doesn''t match mine. In mine, all the
Insert
>>methods return wxSizerItem pointers. Oddly, the 2.5.3 wx docs claim
>>those methods return void. [...Researching...]. Ok, the wxWidgets CVS
>>tree shows that the DEBIAN_2_5_3_2 tag includes a patch that causes
>>wxSizer::Insert to return a wxSizerItem*. The vanilla WX_2_5_3 tag had
>>them declared as void returns. Grrrrr.
>>
>>I''m still trying to figure out how to support different
versions of wx
>>where they have conflicting API''s. If we put conditionals in
the
>>swig/classes/include/.h files, then the files in src/ will be
>>version-dependent. That may be unavoidable, but I would sure like to
>>either minimize it, or embrace it by having multiple src/ directories
>>(src/2.5.3/ and src/2.6.1/ etc.). Hm. That''s probably the way
to go.
>>Comments?
>>
>>Thanks,
>>
>>Kevin
>>    
>>
>
>hmm.... indeed. This is quite a problem, I looked at the 2.6.1 code and
>it''s broken (on multiple places) with 2.5.3. Building wxruby2
against
>2.6 fails as well only at a different class now:
>----
>i686-pc-linux-gnu-g++  -c -I/usr/lib/wx/include/gtk2-ansi-release-2.6
>-I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__
>-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1  -O2
>-march=i686  -fPIC   -I /usr/lib/ruby/site_ruby/1.8 -I
>/usr/lib/ruby/site_ruby/1.8/i686-linux -I /usr/lib/ruby/site_ruby -I
>/usr/lib/ruby/1.8 -I /usr/lib/ruby/1.8/i686-linux -I . -o obj/Icon.o
>src/Icon.cpp
>src/Icon.cpp: In constructor `SwigDirector_wxIcon::SwigDirector_wxIcon(long
>   unsigned int, const wxString&, long int, int, int, bool)'':
>src/Icon.cpp:789: error: invalid conversion from `long int'' to
>`wxBitmapType''
>src/Icon.cpp:789: error:   initializing argument 2 of `wxIcon::wxIcon(const
>   wxString&, wxBitmapType, int, int)''
>src/Icon.cpp: In function `VALUE _wrap_new_wxIcon(int, VALUE*, long unsigned
>   int)'':
>src/Icon.cpp:847: error: invalid conversion from `long int'' to
>`wxBitmapType''
>src/Icon.cpp:847: error:   initializing argument 2 of `wxIcon::wxIcon(const
>   wxString&, wxBitmapType, int, int)''
>----
>It does compile Sizer.i correctly however :))
>
>Is there a specific and compelling reason you want to support the 2.5
>release of wx? I think it''d be quite acceptable to require 2.6.1
>especially because the 2.5 series is considered a development-branch.
>(see http://www.wxwidgets.org/roadmap.htm )
>It would simplify matters greatly.
>
>If it''s a matter of package availability, well we could always try
to
>create and distribute the needed ones ourselves (just a thought).
>
>Thanks,
>Jonathan
>_______________________________________________
>wxruby-users mailing list
>wxruby-users@rubyforge.org
>http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/wxruby-users/attachments/20050731/1ea8dbd6/attachment-0001.htm

Jonathan Maasland wrote:
> 
> hmm.... indeed. This is quite a problem, I looked at the 2.6.1 code and
> it''s broken (on multiple places) with 2.5.3. Building wxruby2
against
> 2.6 fails as well only at a different class now:
> ----
> i686-pc-linux-gnu-g++  -c -I/usr/lib/wx/include/gtk2-ansi-release-2.6
> -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__
> -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1  -O2
> -march=i686  -fPIC   -I /usr/lib/ruby/site_ruby/1.8 -I
> /usr/lib/ruby/site_ruby/1.8/i686-linux -I /usr/lib/ruby/site_ruby -I
> /usr/lib/ruby/1.8 -I /usr/lib/ruby/1.8/i686-linux -I . -o obj/Icon.o
> src/Icon.cpp
> src/Icon.cpp: In constructor `SwigDirector_wxIcon::SwigDirector_wxIcon(long
>    unsigned int, const wxString&, long int, int, int, bool)'':
> src/Icon.cpp:789: error: invalid conversion from `long int'' to
> `wxBitmapType''
Hm. I thought Sean and I had fixed that already. I guess not.
> Is there a specific and compelling reason you want to support the 2.5
> release of wx? 
Well, there is a specific and compelling selfish reason: I''m using 
Ubuntu Linux, and they offer wx 2.5.3 (Debian variant) in their standard 
package repository. I really hate installing libraries outside the apt 
package manager because it screws up all the dependency checking.
> If it''s a matter of package availability, well we could always try
to
> create and distribute the needed ones ourselves (just a thought).
That''s a good point. Since Ubuntu seems to be one of the few systems 
where 2.6 is not at least as available as 2.5, I should probably package 
up an Ubuntu 2.6. It''s not enough for me to have it as a .DEB. I want
it
hosted at an apt repo somewhere on the internet. Fortunately, I recently 
learned how to host my own apt repo, so this now seems like an appealing 
option.

Ok. I''m almost convinced that we should go with wx 2.6. Are there any 
volunteers to build an Ubuntu package that I could host? If not, I''ll 
have to fumble through it myself, but assuming I can get it working, 
I''ll drop 2.5 and everything will get much simpler.

Thanks,

Kevin

Jonathan Maasland wrote:
> I removed Icon.(cpp h i) and the build finished succesfully. However
> running the samples gives me an ugly segmentation fault without any
> meaningful message or reason:
> ----
> ruby -I lib/ samples/controls/controls.rb
> lib/wxruby2.so: [BUG] Segmentation fault
> ruby 1.8.2 (2004-12-25) [i686-linux]
> 
> Aborted
> ----
> Is there a way to set a debug flag or such so I can find out why and
> where it failed?
You can run it inside gdb, and at least get a stack trace. I''m no gdb 
expert but if I remember correctly, you would do something like:

gdb ruby
set args samples/controls/controls.rb
run
(program segfaults)
bt


You should definitely start with minimal, as it is the simplest sample 
we have. It''s not quite truly minimal because it has an icon, menu bar,
and status bar. You could try commenting those out, too.

Kevin

> Ok. I''m almost convinced that we should go with wx 2.6. Are there
any
> volunteers to build an Ubuntu package that I could host? If not,
I''ll
> have to fumble through it myself, but assuming I can get it working,
> I''ll drop 2.5 and everything will get much simpler.
wx-2.6.1 was just uploaded to ubuntu breezy, so I think it''s ok to
drop 2.5 support if it eases things.

Jani

Jani Monoses wrote:
> wx-2.6.1 was just uploaded to ubuntu breezy, so I think it''s ok to
> drop 2.5 support if it eases things.
> 
Ok. I''m convinced. Tonight I upgraded my system to 2.6.1 (using the wx 
official tarball source). Later, when I upgrade to Breezy, I''ll switch 
back to using the official Ubuntu packages.

wxruby2 will only support wx 2.6+

Thanks,

Kevin