Hi,
I am trying to compile qtruby. Unfortunally it failed with the following error
message:
Qt.cpp: In function `VALUE initialize_qt(int, VALUE*, VALUE)':
Qt.cpp:1145: error: ISO C++ forbids cast to non-reference type used as lvalue
make[5]: *** [Qt.lo] Fehler 1
Maybe this is due to the gcc version I am using? It's gcc 3.4.1. Well, I
thought I'll give it a try on my other box running slackware 10.0 with gcc
3.3.4. But here, ./configure can't find my X includes -- I tried to pass an
option to point there directly, but still the same. Maybe this is since
slackware 10.0 ships with x11-6.7.0? Hm, I thought it should be compatible to
XF86...
Has anyone managed to compile qtruby? Any idea how I could do it as well?
regards,
jochen
I'm afraid I'm not much help as I didn't get this error, but I was able to compile it. Debian sarge.
Jochen Immendörfer wrote:
···
Hi,
I am trying to compile qtruby. Unfortunally it failed with the following error message:
Qt.cpp: In function `VALUE initialize_qt(int, VALUE*, VALUE)':
Qt.cpp:1145: error: ISO C++ forbids cast to non-reference type used as lvalue
make[5]: *** [Qt.lo] Fehler 1
Maybe this is due to the gcc version I am using? It's gcc 3.4.1. Well, I thought I'll give it a try on my other box running slackware 10.0 with gcc 3.3.4. But here, ./configure can't find my X includes -- I tried to pass an option to point there directly, but still the same. Maybe this is since slackware 10.0 ships with x11-6.7.0? Hm, I thought it should be compatible to XF86...
Has anyone managed to compile qtruby? Any idea how I could do it as well?
regards,
jochen
I'm not a qtruby developer and I don't have Qt 3.2, so I can't check any
of this, but it looks like a bug.
Lines 1144-1145 read:
smokeruby_object * p = 0;
Data_Get_Struct(temp_obj, smokeruby_object, (void *) p);
And this expands to:
smokeruby_object * p = 0;
Check_Type(temp_obj, T_DATA); (void *) p = (smokeruby_object*)DATA_PTR(temp_obj);
Which is not valid C++ (older versions of g++ accept it, but neither
como nor g++ 3.4 does).
There's really no good reason I can think of for the cast to void*,
anyway. You should submit a bug report.
Paul
···
On Wed, Jul 14, 2004 at 01:40:23AM +0900, Jochen Immendörfer wrote:
Hi,
I am trying to compile qtruby. Unfortunally it failed with the following error
message:
Qt.cpp: In function `VALUE initialize_qt(int, VALUE*, VALUE)':
Qt.cpp:1145: error: ISO C++ forbids cast to non-reference type used as lvalue
make[5]: *** [Qt.lo] Fehler 1
Thank you two for answering.
I already had the intention of submitting a bug report, but -- I just couldn't
find such a possibility at rubyforge. Am I just blind? If you know where to
submit a bug report, please tell me and I'll do.
Btw. I removed the cast to void* from line 1145 and it did actually compile
after then..
But trying
require 'Qt'
in irb produces a segmentation fault 
regards,
jochen
···
Am Dienstag 13 Juli 2004 19:14 schrieb Paul Brannan:
On Wed, Jul 14, 2004 at 01:40:23AM +0900, Jochen Immendörfer wrote:
> Hi,
>
> I am trying to compile qtruby. Unfortunally it failed with the following
> error message:
>
> Qt.cpp: In function `VALUE initialize_qt(int, VALUE*, VALUE)':
> Qt.cpp:1145: error: ISO C++ forbids cast to non-reference type used as
> lvalue make[5]: *** [Qt.lo] Fehler 1
I'm not a qtruby developer and I don't have Qt 3.2, so I can't check any
of this, but it looks like a bug.
Lines 1144-1145 read:
smokeruby_object * p = 0;
Data_Get_Struct(temp_obj, smokeruby_object, (void *) p);
And this expands to:
smokeruby_object * p = 0;
Check_Type(temp_obj, T_DATA); (void *) p =
(smokeruby_object*)DATA_PTR(temp_obj);
Which is not valid C++ (older versions of g++ accept it, but neither
como nor g++ 3.4 does).
There's really no good reason I can think of for the cast to void*,
anyway. You should submit a bug report.
Paul
Ok, I did one more try. This time on my notebook -- same distribution like
before same gcc version (Arch Linux, gcc 3.4.1). Cast to void* removed from
line 1145. Here it worked. Without segmentation fault. Nice. But I still
don't know where to submit a bug report 
regards,
jochen
···
Am Dienstag 13 Juli 2004 19:32 schrieb Jochen Immendörfer:
Thank you two for answering.
I already had the intention of submitting a bug report, but -- I just
couldn't find such a possibility at rubyforge. Am I just blind? If you know
where to submit a bug report, please tell me and I'll do.
Btw. I removed the cast to void* from line 1145 and it did actually compile
after then..
But trying
require 'Qt'
in irb produces a segmentation fault
regards,
jochen
Am Dienstag 13 Juli 2004 19:14 schrieb Paul Brannan:
> On Wed, Jul 14, 2004 at 01:40:23AM +0900, Jochen Immendörfer wrote:
> > Hi,
> >
> > I am trying to compile qtruby. Unfortunally it failed with the
> > following error message:
> >
> > Qt.cpp: In function `VALUE initialize_qt(int, VALUE*, VALUE)':
> > Qt.cpp:1145: error: ISO C++ forbids cast to non-reference type used as
> > lvalue make[5]: *** [Qt.lo] Fehler 1
>
> I'm not a qtruby developer and I don't have Qt 3.2, so I can't check any
> of this, but it looks like a bug.
>
> Lines 1144-1145 read:
>
> smokeruby_object * p = 0;
> Data_Get_Struct(temp_obj, smokeruby_object, (void *) p);
>
> And this expands to:
>
> smokeruby_object * p = 0;
> Check_Type(temp_obj, T_DATA); (void *) p =
> (smokeruby_object*)DATA_PTR(temp_obj);
>
> Which is not valid C++ (older versions of g++ accept it, but neither
> como nor g++ 3.4 does).
>
> There's really no good reason I can think of for the cast to void*,
> anyway. You should submit a bug report.
>
> Paul
umm you could submit them to me i guess 
(or kde-bindings@kde.org)
any difference between the two installs? one has a kde install the other not?
Alex
···
On Wed, Jul 14, 2004 at 02:54:22AM +0900, Jochen Immend?rfer wrote:
Ok, I did one more try. This time on my notebook -- same distribution like
before same gcc version (Arch Linux, gcc 3.4.1). Cast to void* removed from
line 1145. Here it worked. Without segmentation fault. Nice. But I still
don't know where to submit a bug report
irb(main):001:0> require 'Qt'
/usr/lib/ruby/site_ruby/1.8/i686-linux/qtruby.so: [BUG] Segmentation fault
ruby 1.8.2 (2004-07-10) [i686-linux]
Speicherzugriffsfehler
That's all I get. (for those who don't understand german:
Speicherzugriffsfehler means segmentation fault)
···
Am Dienstag 13 Juli 2004 20:24 schrieb Alexander Kellett:
On Wed, Jul 14, 2004 at 02:32:36AM +0900, Jochen Immend?rfer wrote:
> require 'Qt'
>
> in irb produces a segmentation fault
whats the backtrace?
cheers,
Alex
ok, should I still submit a report to you or did you already hear about
it? ;))
Both machines have a minimal kde installation. I think both installs should be
very similar. At least the important packages are the same. Same version
everywhere. kde version is 3.2.3, qt is 3.3.2.
Do you need more informations?
regards,
jochen
···
Am Dienstag 13 Juli 2004 20:26 schrieb Alexander Kellett:
On Wed, Jul 14, 2004 at 02:54:22AM +0900, Jochen Immend?rfer wrote:
> Ok, I did one more try. This time on my notebook -- same distribution
> like before same gcc version (Arch Linux, gcc 3.4.1). Cast to void*
> removed from line 1145. Here it worked. Without segmentation fault. Nice.
> But I still don't know where to submit a bug report
umm you could submit them to me i guess (or kde-bindings@kde.org)
any difference between the two installs? one has a kde install the other
not?
Alex
can you run in gdb?
backtrace is reallllly needed
Alex
···
On Wed, Jul 14, 2004 at 03:29:33AM +0900, Jochen Immend?rfer wrote:
irb(main):001:0> require 'Qt'
/usr/lib/ruby/site_ruby/1.8/i686-linux/qtruby.so: [BUG] Segmentation fault
ruby 1.8.2 (2004-07-10) [i686-linux]
Speicherzugriffsfehler
That's all I get. (for those who don't understand german:
Speicherzugriffsfehler means segmentation fault)
hm.. I'm sorry to say so, but I don't now how to do this. If you tell me what
I exactly have to do, I'll give my best
···
can you run in gdb?
backtrace is reallllly needed
Alex
no thats okay. with the backtrace i should be able to figure out
whats wrong. and if i already know the fix or not there is a
workaround for a pthread related backtrace available but i didn't
port this to the qtruby only version for the moment.
Alex
···
On Wed, Jul 14, 2004 at 03:37:06AM +0900, Jochen Immend?rfer wrote:
Both machines have a minimal kde installation. I think both installs should be
very similar. At least the important packages are the same. Same version
everywhere. kde version is 3.2.3, qt is 3.3.2.
Do you need more informations?
start gdb with:
gdb ruby
then try
run -e "require 'Qt'"
can't test... don't have a working x11 installation :s
but it should work if i remember gdb correctly 
Alex
···
On Wed, Jul 14, 2004 at 03:41:56AM +0900, Jochen Immend?rfer wrote:
hm.. I'm sorry to say so, but I don't now how to do this. If you tell me what
I exactly have to do, I'll give my best
>
> can you run in gdb?
> backtrace is reallllly needed
>
> Alex
Ok, I must confess I have not much experience in using gdb, but here is what I
get:
$ gdb ruby
(gdb) run -e "require 'Qt'"
Starting program: /usr/bin/ruby -e "require 'Qt'"
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...[Thread debugging
using libthread_db enabled]
[New Thread 16384 (LWP 20408)]
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 20408)]
0x40fd86f9 in __pthread_unlock () from /lib/libpthread.so.0
(gdb)
(gdb) backtrace
#0 0x40fd86f9 in __pthread_unlock () from /lib/libpthread.so.0
#1 0x40fd5d15 in pthread_mutex_unlock () from /lib/libpthread.so.0
#2 0x40242a5b in _dl_open () from /lib/libc.so.6
#3 0x400ebe8b in dlopen_doit () from /lib/libdl.so.2
#4 0x4000ad76 in _dl_catch_error_internal () from /lib/ld-linux.so.2
#5 0x400ec276 in _dlerror_run () from /lib/libdl.so.2
#6 0x400ebed4 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2
#7 0x40041e07 in dln_load () from /usr/lib/libruby.so.1.8
#8 0x4005b48e in rb_require_safe () from /usr/lib/libruby.so.1.8
#9 0x0000002e in ?? ()
#10 0x00000000 in ?? ()
#11 0x00000000 in ?? ()
#12 0x00000000 in ?? ()
#13 0x00000000 in ?? ()
#14 0x08079518 in ?? ()
#15 0xbfffe318 in ?? ()
#16 0xbfffe31c in ?? ()
#17 0x40289100 in ?? ()
#18 0x00000000 in ?? ()
#19 0x00000004 in ?? ()
#20 0x00000000 in ?? ()
#21 0x402890b0 in ?? ()
#22 0x40289060 in ?? ()
---Type <return> to continue, or q <return> to quit---
#23 0x402890b0 in ?? ()
#24 0x400da214 in __JCR_LIST__ () from /usr/lib/libruby.so.1.8
#25 0x402989e8 in ?? ()
#26 0x4005b690 in rb_require () from /usr/lib/libruby.so.1.8
Previous frame inner to this frame (corrupt stack?)
(gdb)
If this still isn't what you need, let me know.
regards,
jochen
···
Am Dienstag 13 Juli 2004 21:04 schrieb Alexander Kellett:
start gdb with:
gdb ruby
then try
run -e "require 'Qt'"
can't test... don't have a working x11 installation :s
but it should work if i remember gdb correctly
Alex
On Wed, Jul 14, 2004 at 03:41:56AM +0900, Jochen Immend?rfer wrote:
> hm.. I'm sorry to say so, but I don't now how to do this. If you tell me
> what I exactly have to do, I'll give my best
>
> > can you run in gdb?
> > backtrace is reallllly needed
> >
> > Alex
Jochen Immendörfer wrote:
Ok, I must confess I have not much experience in using gdb, but here is
what I get:
$ gdb ruby
(gdb) run -e "require 'Qt'"
Starting program: /usr/bin/ruby -e "require 'Qt'"
(no debugging symbols found)...(no debugging symbols found)...(no
This is a known problem - there is some sort of incompatibility between Qt
and ruby on startup. The fix is to start your program via 'krubyinit'
(found in korundum/bin).
-- Richard
This is a known problem - there is some sort of incompatibility between Qt
and ruby on startup. The fix is to start your program via 'krubyinit'
(found in korundum/bin).
-- Richard
Hi, thanks for the information.
I found krubyinit.cpp here:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/kdebindings/korundum/bin/krubyinit.cpp?rev=1.3&content-type=text/plain
I tried to compile it with:
$ gcc -I/usr/lib/ruby/1.8/i686-linux -o krubyinit krubyinit.cpp -lruby
and received the error:
/tmp/cc5G9T5J.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
Is there anything else needed to link it with?
regards,
jochen
if i'm not busy this weekend i'll try and do
qrubyinit and release a new qtruby tarball.
n.b. i'll inevitably be quite busy
Alex
···
On Wed, Jul 14, 2004 at 02:24:33PM +0900, Jochen Immend?rfer wrote:
> This is a known problem - there is some sort of incompatibility between Qt
> and ruby on startup. The fix is to start your program via 'krubyinit'
> (found in korundum/bin).
>
> -- Richard
Hi, thanks for the information.
I found krubyinit.cpp here:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/kdebindings/korundum/bin/krubyinit.cpp?rev=1.3&content-type=text/plain
I tried to compile it with:
$ gcc -I/usr/lib/ruby/1.8/i686-linux -o krubyinit krubyinit.cpp -lruby
and received the error:
/tmp/cc5G9T5J.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
Is there anything else needed to link it with?
regards,
jochen
mvg,
Alex
--
When women love us, they forgive us everything, even our crimes; when they do
not love us, they give us credit for nothing, not even our virtues.
-- Honor'e de Balzac
Jochen Immendörfer wrote:
This is a known problem - there is some sort of incompatibility between
Qt and ruby on startup. The fix is to start your program via 'krubyinit'
(found in korundum/bin).
-- Richard
Hi, thanks for the information.
I found krubyinit.cpp here:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/kdebindings/korundum/bin/krubyinit.cpp?rev=1.3&content-type=text/plain
I tried to compile it with:
$ gcc -I/usr/lib/ruby/1.8/i686-linux -o krubyinit krubyinit.cpp -lruby
and received the error:
/tmp/cc5G9T5J.o(.eh_frame+0x11): undefined reference to
`__gxx_personality_v0'
Is there anything else needed to link it with?
I haven't heard of that one before. The build problem I had with krubyinit
was that it was expecting to link against libruby.so, and ruby didn't build
that be default. I needed to use '--enable-shared' configure option and
build ruby. I searched google for your error, and it looks like you need to
link with g++ rather than gcc.
-- Richard
Alexander Kellett wrote:
if i'm not busy this weekend i'll try and do
qrubyinit and release a new qtruby tarball.
n.b. i'll inevitably be quite busy
Alex
Do you really mean 'qrubyinit' or was it a typo for 'qtrubyinit'? I've fixed
the '(void *)' cast problem in the kde cvs now.
-- Richard
qtrubyinit sounds better in fact.
i wasn't really sure
Alex
···
On Wed, Jul 14, 2004 at 07:52:20PM +0900, Richard Dale wrote:
Do you really mean 'qrubyinit' or was it a typo for 'qtrubyinit'? I've fixed
the '(void *)' cast problem in the kde cvs now.
-- Richard