From: Luigi Ballabio <ballabio@...>
Date: 2002-02-16T05:24:30+09:00
Subject: Re: SWIG/Ruby woes with g++ 3.0


Hi Paul,

At 12:22 AM +0900 2/16/02, Paul Brannan wrote:
>On Fri, Feb 15, 2002 at 06:11:58PM +0900, Luigi Ballabio wrote:
>>
>>  Greetings,
>>	I just found a problem with generated SWIG code and g++ 3.0.3 which
>>  escaped me until now since I've been using 2.95.4.
>
>What is 2.95.4?  The latest 2.95 version listed on gcc.gnu.org is
>2.95.3.

Oh, really? Well, that's what 'g++ -version' returned on my box.
I didn't check the gnu site though--I trusted Debian for installation...

>  >
>>  In short:
>>  1) the SWIG/Ruby wrappers define VALUEFUNC(f) as (VALUE (*)(...))f when
>>  __cplusplus is defined.
>>  2) in the initialization function, VALUEFUNC(f) is passed to
>>  rb_define_method as the 3rd argument
>>  3) However, in intern.h rb_define_method is declared as taking a 3rd
>>  argument of type VALUE (*)(), i.e., no ellipsis
>
>Hmm, rb_define_method is in ruby.h on Ruby 1.6.5.  What version of Ruby
>are you using?

I'm writing for home now and I can't check, but I believe it's 1.6.6.

>The tricky part comes when the function being called is declared as
>extern "C".  Gcc 2.95.x treats such a function C-style; gcc 3.0.x treats
>it C++-style.

So that's why 2.95 compiled. Once I looked at intern.h I wasn't 
surprised that 3.0.x complained---I was surprised that 2.95.x 
didn't...

>However, if you cannot move to Ruby 1.7, then try adding the following
>to your swig file:
>
>   %{
>   #define rb_define_method(klass, name, func, params) \
>           rb_define_method(klass, name, (VALUE(*)(...))(func), params)
>   %}

Hmm, I don't think it would work. The above is just the VALUEFUNC 
macro made explicit---which is what the wrappers do already. The 
problem is that the declarations in intern.h should be changed.

Thanks anyway,
		Luigi

--