SWIG generates some code that compares the result of rb_respond_to to Qtrue. This causes runtime errors in ruby 1.9. The fix I think should be to remove the "== Qtrue", since both 1.8 and 1.9 should give you the correct result. In neither version does it appear to me that it is safe to assume you are getting a Qtrue/Qfalse result. I've not unravelled it far enough to see why this was working in previous versions.
It may be that the original SWIG implementation saw the code of obj_respond_to (a static function not accessible to swig) that does return Qtrue or Qfalse. That one is the function ultimately called by the interpreter when you call the ruby method respond_to?, but I don't think it is safe to treat rb_respond_to as returning Qtrue for a "true" result in either version.
See rb_respond_to, rb_obj_respond_to in the ruby source code (vm_method.c for 1.9, eval.c for 1.8).
Examples of where SWIG does this include these two functions. These functions aren't used anywhere except in my own custom typemaps (at least in my test case) but they will not work. At least in my test case SWIG doesn't do this anywhere else.
int SWIG_Ruby_isCallable( VALUE proc )
if ( rb_respond_to( proc, swig_call_id ) == Qtrue )
int SWIG_Ruby_arity( VALUE proc, int minimal )
if ( rb_respond_to( proc, swig_arity_id ) == Qtrue )
VALUE num = rb_funcall( proc, swig_arity_id, 0 );
int arity = NUM2INT(num);
if ( arity < 0 && (arity+1) < -minimal ) return 1;
if ( arity == minimal ) return 1;