Upgrading 1.8.6 to 1.8.6-p36 has stopped C++ extensions from
compiling. If I create a file foo.cc containing:
#include <ruby.h>
and compile it with:
$ g++ -I/usr/lib/ruby/1.8/i686-linux -c foo.cc
then it works with version 1.8.6 , but fails with version 1.8.6-p36 :
In file included from /usr/lib/ruby/1.8/i686-linux/ruby.h:719,
from foo.cc:1:
/usr/lib/ruby/1.8/i686-linux/intern.h:207: error: use of enum
`rb_thread_status’ without previous declaration
/usr/lib/ruby/1.8/i686-linux/intern.h:207: error: invalid type in
declaration before ‘;’ token
Toy C extensions compile just fine. Wrapping the ‘#include <ruby.h>’
in “extern “C” { … }” makes no difference. I’m going bonkers trying
to figure this out. Any ideas? I want to resume work on Ruby/FLTK
but I’m stuck until this is fixed, so I’d really appreciate some help.
Details: GNU/Linux, kernel 2.6.21 , gcc 3.4.3 , ruby configuration :
./configure \
--prefix=/usr \
--enable-shared \
--enable-pthread \
--enable-install-doc
Thanks in advance,
Jeremy H.
On 2007-07-30, Jeremy H. [email protected] (ie. me) wrote:
Upgrading 1.8.6 to 1.8.6-p36 has stopped C++ extensions from
compiling.
OK, the problem is that g++ requires you to declare enum’s before
using them and 1.8.6-p36 added some declarations to intern.h that use
an enum defined in node.h . Everything works OK (as far as I can
tell) if I patch intern.h to #include node.h . (Patch supplied at the
end.)
Is there any way to work around this without patching Ruby? I can’t
find one so far.
Regards,
Jeremy H.
diff -ur – 0/intern.h 1/intern.h
— 0/intern.h 2007-06-07 13:40:01.000000000 +0100
+++ 1/intern.h 2007-07-30 17:36:54.972409368 +0100
@@ -19,6 +19,8 @@
#define ID_ALLOCATOR 1
+#include “node.h”
+
/* array.c /
void rb_mem_clear _((register VALUE, register long));
VALUE rb_assoc_new _((VALUE, VALUE));
On Tue, 2007-07-31 at 02:24 +0900, Jeremy H. wrote:
OK, the problem is that g++ requires you to declare enum’s before
using them and 1.8.6-p36 added some declarations to intern.h that use
an enum defined in node.h . Everything works OK (as far as I can
tell) if I patch intern.h to #include node.h . (Patch supplied at the
end.)
Is there any way to work around this without patching Ruby? I can’t
find one so far.
Would forward-declaring the enum before including either header work?
-mental
Hi,
At Tue, 31 Jul 2007 01:10:06 +0900,
Jeremy H. wrote in [ruby-talk:262491]:
Upgrading 1.8.6 to 1.8.6-p36 has stopped C++ extensions from
compiling. If I create a file foo.cc containing:
First, 1.8 doesn’t support C++ officially yet.
then it works with version 1.8.6 , but fails with version 1.8.6-p36 :
In file included from /usr/lib/ruby/1.8/i686-linux/ruby.h:719,
from foo.cc:1:
/usr/lib/ruby/1.8/i686-linux/intern.h:207: error: use of enum `rb_thread_status' without previous declaration
/usr/lib/ruby/1.8/i686-linux/intern.h:207: error: invalid type in declaration before ';' token
Already fixed in the SVN repository.
On 2007-07-30, MenTaLguY [email protected] wrote:
On Tue, 2007-07-31 at 02:24 +0900, Jeremy H. wrote:
OK, the problem is that g++ requires you to declare enum’s before
using them and 1.8.6-p36 added some declarations to intern.h that
use an enum defined in node.h .
Would forward-declaring the enum before including either header
work?
I thought of that but I couldn’t get it to work. I tried adding “enum
<missing_enum_name>;” but g++ raised the same error as before. It
insists on a definition of the enum; a declaration is not enough, at
least as far as I can tell. If anyone smarter than I can make this
work then I would really love to know!
Regards,
Jeremy H.
On 2007-07-30, Nobuyoshi N. [email protected] wrote:
First, 1.8 doesn’t support C++ officially yet.
Gosh! That’s a surprise - this is the first time there have been
problems like this with Ruby/FLTK. I just assumed it was supposed to
work. How do projects like qtruby deal with this?
then it works with version 1.8.6 , but fails with version 1.8.6-p36 :
In file included from /usr/lib/ruby/1.8/i686-linux/ruby.h:719,
from foo.cc:1:
/usr/lib/ruby/1.8/i686-linux/intern.h:207: error: use of enum `rb_thread_status' without previous declaration
/usr/lib/ruby/1.8/i686-linux/intern.h:207: error: invalid type in declaration before ';' token
Already fixed in the SVN repository.
( /me builds from SVN. ) So it is! Excellent! Will there be another
patch version of 1.8.6 ?
Regards,
Jeremy H.
On 2007-07-31, Nobuyoshi N. [email protected] wrote:
Jeremy H. wrote in [ruby-talk:262593]:
[ Nobuyoshi N. wrote:]
First, 1.8 doesn’t support C++ officially yet.
How do projects like qtruby deal with this?
Perhaps, SWIG does it.
Ah, I didn’t think of that. Ruby/FLTK doesn’t use SWIG.
Will there be another patch version of 1.8.6 ?
The next patch release is planned in September.
Excellent!
Thanks for taking the time to reply.
Jeremy H.
Hi,
At Tue, 31 Jul 2007 16:30:02 +0900,
Jeremy H. wrote in [ruby-talk:262593]:
First, 1.8 doesn’t support C++ officially yet.
Gosh! That’s a surprise - this is the first time there have been
problems like this with Ruby/FLTK. I just assumed it was supposed to
work. How do projects like qtruby deal with this?
Perhaps, SWIG does it. CXX, CXXFLAGS are not in rbconfig.rb.
Already fixed in the SVN repository.
( /me builds from SVN. ) So it is! Excellent! Will there be another
patch version of 1.8.6 ?
The next patch release is planned in September.
Hi,
At Wed, 1 Aug 2007 02:35:02 +0900,
Jeremy H. wrote in [ruby-talk:262682]:
First, 1.8 doesn’t support C++ officially yet.
How do projects like qtruby deal with this?
Perhaps, SWIG does it.
Ah, I didn’t think of that. Ruby/FLTK doesn’t use SWIG.
I don’t mean extension libraries written in C++ can never work
with 1.8, but just it isn’t guaranteed officially.
Hi,
At Wed, 1 Aug 2007 19:40:06 +0900,
Jeremy H. wrote in [ruby-talk:262802]:
Is there any reason not to guarantee it?
No and no reason to guarantee.
The problem with 1.8.6-p36
is the only glitch I’ve seen with the C headers and that seems to have
been easily fixed. How much effort would it be to make mkmf.rb
support C++?
See mkmf.rb in 1.9.
On 2007-07-31, Nobuyoshi N. [email protected] wrote:
I don’t mean extension libraries written in C++ can never work with
1.8, but just it isn’t guaranteed officially.
Is there any reason not to guarantee it? The problem with 1.8.6-p36
is the only glitch I’ve seen with the C headers and that seems to have
been easily fixed. How much effort would it be to make mkmf.rb
support C++?
Regards,
Jeremy H.