[Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

Dirk Eddelbuettel
Folks,

Here is another g++-3.0 bug report regarding quantlib, or in particular the
Ruby bindings. I'd appreciate any comments. Luigi?

Dirk

----- Forwarded message from LaMont Jones <[hidden email]> -----

Envelope-to: [hidden email]
Delivery-date: Thu, 14 Feb 2002 10:33:09 -0600
Subject: Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)
Reply-To: LaMont Jones <[hidden email]>, [hidden email]
From: LaMont Jones <[hidden email]>
To: [hidden email]

Package: quantlib-ruby
Version: 0.2.1cvs20020120-2
Severity: important

Build fails due to g++ 3.0 errors.  Full build log at:
    http://buildd.debian.org/fetch.php?&pkg=quantlib-ruby&ver=0.2.1cvs20020120-2&arch=hppa&stamp=1011978461&file=log&as=raw

g++ -fPIC -g -O2 -fPIC  -DHAVE_CONFIG_H -I. -I/usr/lib/ruby/1.6/hppa-linux -I. -I/usr/include    -I/usr/local/include -c -o quantlib_wrap.o quantlib_wrap.cpp
quantlib_wrap.cpp: In function `void Init_QuantLibc()':
quantlib_wrap.cpp:18130: cannot convert `VALUE (*)(...)' to `VALUE (*)()' for
   argument `3' to `void rb_define_singleton_method(long unsigned int, const
   char*, VALUE (*)(), int)'
...

-- System Information
Debian Release: 3.0
Kernel Version: Linux smallone 2.4.17-64 #1 Wed Jan 30 00:23:46 MST 2002 parisc64 unknown



----- End forwarded message -----

--
Good judgement comes from experience; experience comes from bad judgement.
                                                            -- Fred Brooks


Reply | Threaded
Open this post in threaded view
|

Re: [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

Luigi Ballabio-4
At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
>Here is another g++-3.0 bug report regarding quantlib, or in particular the
>Ruby bindings. I'd appreciate any comments. Luigi?

Ouch.
It's not just an hppa problem. It seems like SWIG/Ruby bindings have a big
problem with g++ 3.0 - I just reproduced it on i386. Unfortunately it's not
our code---it's either the Ruby API or the SWIG-generated wrappers. I just
sent a mail to the relevant mailing lists to ask for insight. We'll see.

In the meantime, would it be possible to compile with 2.95.x on hppa?

Bye,
         Luigi

P.S. Dirk: I sent my public key to James Troup for access to sarti about 10
days ago, but I didn't have any answer. Could you check the thing? Thanks



Reply | Threaded
Open this post in threaded view
|

Re: [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

Dirk Eddelbuettel
On Fri, Feb 15, 2002 at 10:36:21AM +0000, Luigi Ballabio wrote:

> At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
> >Here is another g++-3.0 bug report regarding quantlib, or in particular the
> >Ruby bindings. I'd appreciate any comments. Luigi?
>
> Ouch.
> It's not just an hppa problem. It seems like SWIG/Ruby bindings have a big
> problem with g++ 3.0 - I just reproduced it on i386. Unfortunately it's not
> our code---it's either the Ruby API or the SWIG-generated wrappers. I just
> sent a mail to the relevant mailing lists to ask for insight. We'll see.
>
> In the meantime, would it be possible to compile with 2.95.x on hppa?

IIRC, no. On ia64 we can choose between 2.95.* and 3.0.* but for a reason I
always forget we prefer 3.0.*.

On the hppa architecture, however, only 3.0.* is supported. 2.95.* simply
does not exist.

Dirk

--
Good judgement comes from experience; experience comes from bad judgement.
                                                            -- Fred Brooks


Reply | Threaded
Open this post in threaded view
|

Re: [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

Luigi Ballabio-4
At 7:49 AM -0600 2/15/02, Dirk Eddelbuettel wrote:
>On Fri, Feb 15, 2002 at 10:36:21AM +0000, Luigi Ballabio wrote:
>>  At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
>>  >Here is another g++-3.0 bug report regarding quantlib, or in particular the
>  > >Ruby bindings. I'd appreciate any comments. Luigi?

Ok, here's the final word from the Ruby gurus.

It's a bug in the Ruby headers. It needs a fix in Ruby which has been
done in the Ruby development branch (Ruby 1.7.something) but not in
the current release (or at least not the one in Woody. I don't know
which version of Ruby you have in... wait, what was the name of the
character now? Well, unstable anyway)
It also needs a minor fix in SWIG which has been done in CVS but
wasn't released either.

The bottom line is, we're out in the cold :(
Architectures with gcc 3.0.x are ruled out for the time being.

Sorry,
        Luigi

--


Reply | Threaded
Open this post in threaded view
|

Re: [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

Dirk Eddelbuettel
Luigi,

Thanks a big bunch for getting the nasty details out from under the carpet...

On Fri, Feb 15, 2002 at 09:31:06PM +0100, Luigi Ballabio wrote:

> At 7:49 AM -0600 2/15/02, Dirk Eddelbuettel wrote:
> >On Fri, Feb 15, 2002 at 10:36:21AM +0000, Luigi Ballabio wrote:
> >> At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
> >> >Here is another g++-3.0 bug report regarding quantlib, or in particular
> >> the
> > > >Ruby bindings. I'd appreciate any comments. Luigi?
>
> Ok, here's the final word from the Ruby gurus.
>
> It's a bug in the Ruby headers. It needs a fix in Ruby which has been
> done in the Ruby development branch (Ruby 1.7.something) but not in
> the current release (or at least not the one in Woody. I don't know
> which version of Ruby you have in... wait, what was the name of the
> character now? Well, unstable anyway)

It's called "sid".  There is a ruby1.7_1.7.2.0cvs2002.01.18-1 package.
We could try that.

> It also needs a minor fix in SWIG which has been done in CVS but
> wasn't released either.

Okay, but as we figured, I don't need, or should, re-run swig anyway. So if
you can get hands on a reworked version, we could try a new QL snapshort of
QuantLib-Ruby. If we want it that badly which maybe we don't.

> The bottom line is, we're out in the cold :(
> Architectures with gcc 3.0.x are ruled out for the time being.

That's probably ok, especially as the fix will be forthcoming.

LaMont:  In a situation like this, is it ok if I actually prevent building
on hppa and ia64 via an explicit Architecture: tag in debian/control?

Dirk

--
Good judgement comes from experience; experience comes from bad judgement.
                                                            -- Fred Brooks


Reply | Threaded
Open this post in threaded view
|

Re: Bug#133913: [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

LaMont Jones-8
In reply to this post by Luigi Ballabio-4
> In the meantime, would it be possible to compile with 2.95.x on hppa?

hppa is not supported in gcc 2.x, gcc 3.0 is required.

lamont


Reply | Threaded
Open this post in threaded view
|

Re: [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

LaMont Jones-8
In reply to this post by Dirk Eddelbuettel
> IIRC, no. On ia64 we can choose between 2.95.* and 3.0.* but for a reason I
> always forget we prefer 3.0.*.

Minor nit: ia64 requires 2.96, not 2.95.

> On the hppa architecture, however, only 3.0.* is supported. 2.95.* simply
> does not exist.


Reply | Threaded
Open this post in threaded view
|

Re: [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

LaMont Jones-8
In reply to this post by Dirk Eddelbuettel
> LaMont:  In a situation like this, is it ok if I actually prevent building
> on hppa and ia64 via an explicit Architecture: tag in debian/control?

Better to leave it without the Architecture tag hack, since it _should_
build.  That way, when it does, you don't have to do anything special.
As it sits, uploading a new verison with the arch change will cause the
buildd to try it again, and, well....

The best thing might be to clone the defect over to ruby, and get the
headers fixed in ruby.  Just reassigning the bug is likely to get you
another bug report after I forget the details of _this_ package, and
that'll only get you annoyed... :-)

lamont


Reply | Threaded
Open this post in threaded view
|

Re: [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

LaMont Jones-8
In reply to this post by Luigi Ballabio-4
> Ok, here's the final word from the Ruby gurus.
>
> It's a bug in the Ruby headers. It needs a fix in Ruby which has been
> done in the Ruby development branch (Ruby 1.7.something) but not in
> the current release (or at least not the one in Woody. I don't know
> which version of Ruby you have in... wait, what was the name of the
> character now? Well, unstable anyway)
> It also needs a minor fix in SWIG which has been done in CVS but
> wasn't released either.
>
> The bottom line is, we're out in the cold :(
> Architectures with gcc 3.0.x are ruled out for the time being.

ruby_1.6.6-5 is in sid (which will always be unstable)

Depending on how invasive the fix is, I suppose the ruby maintainer
could port the fix back to ruby 1.6.6-5, and thereby fix all these
ruby-dependants.  Akira?

lamont


Reply | Threaded
Open this post in threaded view
|

Re: [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

akira yamada
Hello,

>>>>> In <[hidden email]>
>>>>> LaMont Jones <[hidden email]> wrote:
> > It's a bug in the Ruby headers. It needs a fix in Ruby which has been
> > done in the Ruby development branch (Ruby 1.7.something) but not in
> > the current release (or at least not the one in Woody. I don't know
> > which version of Ruby you have in... wait, what was the name of the
> > character now? Well, unstable anyway)
> > It also needs a minor fix in SWIG which has been done in CVS but
> > wasn't released either.
> >
> > The bottom line is, we're out in the cold :(
> > Architectures with gcc 3.0.x are ruled out for the time being.
>
> ruby_1.6.6-5 is in sid (which will always be unstable)
>
> Depending on how invasive the fix is, I suppose the ruby maintainer
> could port the fix back to ruby 1.6.6-5, and thereby fix all these
> ruby-dependants.  Akira?

I made a back-port-patch based on results of diffs between 2001-03-27
and 2001-05-03 on *.h, and I attach the patch in this mail. How do you
think about it?  If it is O.K., I will make a new deb-package. (and
will send it to Mr.Matz if it is better to do it by me.)

Thank you.
--
 akira yamada <URL:http://arika.org/ruby/>
 ([hidden email], [hidden email] or [hidden email])


Index: intern.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/intern.h,v
retrieving revision 1.35.2.16
diff -u -r1.35.2.16 intern.h
--- intern.h 13 Feb 2002 09:02:15 -0000 1.35.2.16
+++ intern.h 16 Feb 2002 04:42:15 -0000
@@ -95,13 +95,13 @@
 VALUE rb_class_protected_instance_methods _((int, VALUE*, VALUE));
 VALUE rb_class_private_instance_methods _((int, VALUE*, VALUE));
 VALUE rb_obj_singleton_methods _((VALUE));
-void rb_define_method_id _((VALUE, ID, VALUE (*)(), int));
+void rb_define_method_id _((VALUE, ID, VALUE (*)(ANYARGS), int));
 void rb_frozen_class_p _((VALUE));
 void rb_undef _((VALUE, ID));
-void rb_define_protected_method _((VALUE, const char*, VALUE (*)(), int));
-void rb_define_private_method _((VALUE, const char*, VALUE (*)(), int));
-void rb_define_singleton_method _((VALUE,const char*,VALUE(*)(),int));
-void rb_define_private_method _((VALUE,const char*,VALUE(*)(),int));
+void rb_define_protected_method _((VALUE, const char*, VALUE (*)(ANYARGS), int));
+void rb_define_private_method _((VALUE, const char*, VALUE (*)(ANYARGS), int));
+void rb_define_singleton_method _((VALUE,const char*,VALUE(*)(ANYARGS),int));
+void rb_define_private_method _((VALUE,const char*,VALUE(*)(ANYARGS),int));
 VALUE rb_singleton_class _((VALUE));
 /* enum.c */
 VALUE rb_enum_length _((VALUE));
@@ -167,13 +167,13 @@
 VALUE rb_thread_stop _((void));
 VALUE rb_thread_wakeup _((VALUE));
 VALUE rb_thread_run _((VALUE));
-VALUE rb_thread_create _((VALUE (*)(), void*));
+VALUE rb_thread_create _((VALUE (*)(ANYARGS), void*));
 int rb_thread_scope_shared_p _((void));
 void rb_thread_interrupt _((void));
 void rb_thread_trap_eval _((VALUE, int));
 void rb_thread_signal_raise _((char*));
-int rb_thread_select();
-void rb_thread_wait_for();
+int rb_thread_select(ANYARGS);
+void rb_thread_wait_for(ANYARGS);
 VALUE rb_thread_current _((void));
 VALUE rb_thread_main _((void));
 VALUE rb_thread_local_aref _((VALUE, ID));
@@ -347,7 +347,7 @@
 VALUE rb_struct_aset _((VALUE, VALUE, VALUE));
 VALUE rb_struct_getmember _((VALUE, ID));
 /* time.c */
-VALUE rb_time_new();
+VALUE rb_time_new(ANYARGS);
 /* variable.c */
 VALUE rb_mod_name _((VALUE));
 VALUE rb_class_path _((VALUE));
Index: node.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/node.h,v
retrieving revision 1.18.2.2
diff -u -r1.18.2.2 node.h
--- node.h 6 Apr 2001 05:42:40 -0000 1.18.2.2
+++ node.h 16 Feb 2002 04:43:03 -0000
@@ -131,7 +131,7 @@
  struct RNode *node;
  ID id;
  VALUE value;
- VALUE (*cfunc)();
+ VALUE (*cfunc)(ANYARGS);
  ID *tbl;
     } u1;
     union {
@@ -340,7 +340,7 @@
 NODE *rb_compile_file _((const char*, VALUE, int));
 
 void rb_add_method _((VALUE, ID, NODE *, int));
-NODE *rb_node_newnode();
+NODE *rb_node_newnode(ANYARGS);
 
 struct global_entry *rb_global_entry _((ID));
 VALUE rb_gvar_get _((struct global_entry *));
Index: ruby.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/ruby.h,v
retrieving revision 1.29.2.10
diff -u -r1.29.2.10 ruby.h
--- ruby.h 25 Dec 2001 15:09:05 -0000 1.29.2.10
+++ ruby.h 16 Feb 2002 04:27:48 -0000
@@ -74,6 +74,12 @@
 # define __(args) ()
 #endif
 
+#ifdef __cplusplus
+#define ANYARGS ...
+#else
+#define ANYARGS
+#endif
+
 #ifdef HAVE_ATTR_NORETURN
 # define NORETURN __attribute__ ((noreturn))
 #else
@@ -408,8 +414,8 @@
 #define MEMMOVE(p1,p2,type,n) memmove((p1), (p2), sizeof(type)*(n))
 #define MEMCMP(p1,p2,type,n) memcmp((p1), (p2), sizeof(type)*(n))
 
-void rb_glob _((char*,void(*)(),VALUE));
-void rb_globi _((char*,void(*)(),VALUE));
+void rb_glob _((char*,void(*)(const char*,VALUE),VALUE));
+void rb_iglob _((char*,void(*)(const char*,VALUE),VALUE));
 
 VALUE rb_define_class _((const char*,VALUE));
 VALUE rb_define_module _((const char*));
@@ -420,16 +426,16 @@
 void rb_extend_object _((VALUE,VALUE));
 
 void rb_define_variable _((const char*,VALUE*));
-void rb_define_virtual_variable _((const char*,VALUE(*)(),void(*)()));
-void rb_define_hooked_variable _((const char*,VALUE*,VALUE(*)(),void(*)()));
+void rb_define_virtual_variable _((const char*,VALUE(*)(ANYARGS),void(*)(ANYARGS)));
+void rb_define_hooked_variable _((const char*,VALUE*,VALUE(*)(ANYARGS),void(*)(ANYARGS)));
 void rb_define_readonly_variable _((const char*,VALUE*));
 void rb_define_const _((VALUE,const char*,VALUE));
 void rb_define_global_const _((const char*,VALUE));
 
-#define RUBY_METHOD_FUNC(func) ((VALUE (*)__((...)))func)
-void rb_define_method _((VALUE,const char*,VALUE(*)(),int));
-void rb_define_module_function _((VALUE,const char*,VALUE(*)(),int));
-void rb_define_global_function _((const char*,VALUE(*)(),int));
+#define RUBY_METHOD_FUNC(func) ((VALUE (*)(ANYARGS))func)
+void rb_define_method _((VALUE,const char*,VALUE(*)(ANYARGS),int));
+void rb_define_module_function _((VALUE,const char*,VALUE(*)(ANYARGS),int));
+void rb_define_global_function _((const char*,VALUE(*)(ANYARGS),int));
 
 void rb_undef_method _((VALUE,const char*));
 void rb_define_alias _((VALUE,const char*,const char*));
@@ -479,11 +485,11 @@
 VALUE rb_each _((VALUE));
 VALUE rb_yield _((VALUE));
 int rb_block_given_p _((void));
-VALUE rb_iterate _((VALUE(*)(),VALUE,VALUE(*)(),VALUE));
-VALUE rb_rescue _((VALUE(*)(),VALUE,VALUE(*)(),VALUE));
-VALUE rb_rescue2 __((VALUE(*)(),VALUE,VALUE(*)(),VALUE,...));
-VALUE rb_ensure _((VALUE(*)(),VALUE,VALUE(*)(),VALUE));
-VALUE rb_catch _((const char*,VALUE(*)(),VALUE));
+VALUE rb_iterate _((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE));
+VALUE rb_rescue _((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE));
+VALUE rb_rescue2 __((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE,...));
+VALUE rb_ensure _((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE));
+VALUE rb_catch _((const char*,VALUE(*)(ANYARGS),VALUE));
 void rb_throw _((const char*,VALUE)) NORETURN;
 
 VALUE rb_require _((const char*));
Index: rubysig.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/rubysig.h,v
retrieving revision 1.6
diff -u -r1.6 rubysig.h
--- rubysig.h 16 Nov 2000 07:24:11 -0000 1.6
+++ rubysig.h 16 Feb 2002 04:43:34 -0000
@@ -57,7 +57,7 @@
 #define ALLOW_INTS {rb_prohibit_interrupt--; CHECK_INTS;}
 #define ENABLE_INTS {rb_prohibit_interrupt--;}
 
-VALUE rb_with_disable_interrupt _((VALUE(*)(),VALUE));
+VALUE rb_with_disable_interrupt _((VALUE(*)(ANYARGS),VALUE));
 
 EXTERN rb_atomic_t rb_trap_pending;
 void rb_trap_restore_mask _((void));