qtruby compilation error

  • Thread starter Jochen Immendörfer
  • Start date
J

Jochen Immendörfer

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
 
P

Paul Brannan

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
 
J

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:
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
 
J

Jochen Immendörfer

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:
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
 
A

Alexander Kellett

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 (e-mail address removed))
any difference between the two installs? one has a kde install the other not?

Alex
 
J

Jochen Immendörfer

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:
 
J

Jochen Immendörfer

Am Dienstag 13 Juli 2004 20:26 schrieb Alexander Kellett:
umm you could submit them to me i guess :) (or (e-mail address removed))
any difference between the two installs? one has a kde install the other
not?

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
 
A

Alexander Kellett

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)

can you run in gdb?
backtrace is reallllly needed

Alex
 
J

Jochen Immendörfer

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 ;)
 
A

Alexander Kellett

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?

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
 
A

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 :p
Alex
 
J

Jochen Immendörfer

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:
 
R

Richard Dale

Jochen said:
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
 
J

Jochen Immendörfer

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/cvswe...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
 
A

Alexander Kellett

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

Hi, thanks for the information.
I found krubyinit.cpp here:
http://webcvs.kde.org/cgi-bin/cvswe...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
 
R

Richard Dale

Jochen said:
Hi, thanks for the information.
I found krubyinit.cpp here:
http://webcvs.kde.org/cgi-bin/cvswe...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
 
R

Richard Dale

Alexander said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,756
Messages
2,569,534
Members
45,007
Latest member
OrderFitnessKetoCapsules

Latest Threads

Top