qtruby problems now on linux
Hans Fugal
on my debian box just brings up blank boxes.
Ok, it's probably more related to my having upgraded from sarge to
etch. I rebuilt qtruby (the latest tarball) and reran rbuic on my .ui
files and did just about everything else I could think of, and nothing
has changed.
The hello world demo from the web site works, but anything I create
with qt designer doesn't. In designer preview works normally.
The same code works on my os x laptop, and an earlier version of the
same code worked on this computer too (before I upgraded to etch).
Here's my versions:
ruby 1.8.3
libsmokeqt-dev 4:3.3.2-1
libqt3-mt-dev 3:3.3.4-3
Just for kicks I tried it with libqt0-ruby1.8 4:3.3.2-1 (the debian
korundum package, which is a bit out of date) and got the same results.
(I did a make uninstall from the qtruby source dir before installing
it, and now that I have neither installed it fails on requiring Qt as
expected)
Anyone else on etch having success or failure? What else should I check?
Richard Dale
> Maybe it's related to halloween being tomorrow; all of a sudden qtruby
> on my debian box just brings up blank boxes.
I don't think this is a bug in QtRuby, it seems like there is something
wrong with your setup.
> Ok, it's probably more related to my having upgraded from sarge to
> etch. I rebuilt qtruby (the latest tarball) and reran rbuic on my .ui
> files and did just about everything else I could think of, and nothing
> has changed.
>
> The hello world demo from the web site works, but anything I create
> with qt designer doesn't. In designer preview works normally.
>
> The same code works on my os x laptop, and an earlier version of the
> same code worked on this computer too (before I upgraded to etch).
>
> Here's my versions:
> ruby 1.8.3
> libsmokeqt-dev 4:3.3.2-1
> libqt3-mt-dev 3:3.3.4-3
>
> Just for kicks I tried it with libqt0-ruby1.8 4:3.3.2-1 (the debian
> korundum package, which is a bit out of date) and got the same results.
> (I did a make uninstall from the qtruby source dir before installing
> it, and now that I have neither installed it fails on requiring Qt as
> expected)
>
> Anyone else on etch having success or failure? What else should I check?
Maybe regenerate and rebuild the Smoke library against the Qt 3.3.4 headers.
It has a version of '4:3.3.2-1' which sounds like it was generated against
the Qt 3.3.2 headers, which would be too old. Change to the qtruby/smoke/qt
directory and type 'make clean; make' to rebuild the library, then install
it.
-- Richard
Hans Fugal
fiddling a little more and it looks like the qtruby package builds and
installs its own smoke, so I tried uninstalling Debian's libsmoke* and
rebuilding qtruby. 1.0.10 wouldn't build because of a libtool problem,
but 1.0.9 did. I installed it and had the same problem: a blank window
with no widgets.
Richard Dale
The QtRuby 1.0.10 release depends on the current version of the Smoke
library. I changed the way QByteArrays were marshalled in QtRuby 1.0.10,
and so you can't use a current QtRuby with an old version of the Smoke
library. If there were problems with that, you should see errors about
marshalling QByteArrays on the command line. See this bug report for the
symptoms:
http://bugs.kde.org/show_bug.cgi?id=113994
If you aren't getting any error messages on the command line, I'm not sure
what the problem is. Can you try using 'ldd' on both the Smoke library, and
the qtruby.so extension to see if they are both linked against the same
version of the Qt library. For example:
ldd /usr/local/lib/ruby/site_ruby/1.8/powerpc-linux/qtruby.so
libm.so.6 => /lib/tls/libm.so.6 (0x6ff1b000)
libsmokeqt.so.1 => /opt/kde3/lib/libsmokeqt.so.1 (0x6f98a000)
libqt-mt.so.3 => /opt/kde3/lib/libqt-mt.so.3 (0x6f208000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x6f1d0000)
...
-- Richard
Hans Fugal
Thanks for your help on this very strange bug. The bug you linked to
looks unrelated - in fact I am not getting any console output at all (I
usually get lots of debug stuff... see below)
I know I've gotten confused about what my system looks like, so I can
only imagine how confusing it must be to you. :) Here's the current
state for the rest of this email: no debian smoke or qtruby packages
(i.e. no libqt0-ruby1.8 and no libsmoke*) are installed. I have run
make uninstall in qtruby's source tree too, so I should have no qtruby
on my system, and sure enough "require 'Qt'" fails with "no such file
to load -- Qt".
rm -r qtruby-1.0.10
tar xzf qtruby-1.0.10.tgz
cd qtruby-1.0.10
./configure --with-smoke="qt"
make
The above results in an error:
/bin/sh ../../libtool --silent --tag=CXX --mode=link g++
-Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE
-Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith
-O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -o libsmokeqt.la -rpath
/usr/local/lib -version-info 3:4:92 -no-undefined -Wl,--no-undefined
-Wl,--allow-shlib-undefined -L/usr/share/qt3/lib -L/usr/X11R6/lib
smokedata.lo x_1.lo x_2.lo x_3.lo x_4.lo x_5.lo x_6.lo x_7.lo x_8.lo
x_9.lo x_10.lo x_11.lo x_12.lo x_13.lo x_14.lo x_15.lo x_16.lo x_17.lo
x_18.lo x_19.lo x_20.lo -lqt-mt -lz -lpng -lz -lm -lXext -lX11 -lSM
-lICE -lpthread -lGLU -lGL -lX11
libtool: link: AGE `92' is greater than the current interface number
`3'
libtool: link: `3:4:92' is not valid version information
make[3]: *** [libsmokeqt.la] Error 1
make[3]: Leaving directory `/tmp/qtruby-1.0.10/smoke/qt'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/qtruby-1.0.10/smoke'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/qtruby-1.0.10'
make: *** [all] Error 2
I tried running "make -f Makefile.cvs" too, same result. So 1.0.10 is
out for now since I don't want to fiddle with libtool. ;-)
So I do this:
cd ..; rm -r qtruby-1.0.9; tar xzf qtruby-1.0.9.tgz
make -f Makefile.cvs # (there is no configure in this tarball)
./configure --with-smoke="qt"
make
sudo make install
This time I noticed this at the end of make install:
/usr/bin/ld: warning: libstdc++.so.5, needed by /usr/lib/libqt-mt.so,
may conflict with libstdc++.so.6
Here's the ldd output
$ ldd /usr/local/lib/site_ruby/1.8/i386-linux/qtruby.so
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7f73000)
libsmokeqt.so.1 => /usr/local/lib/libsmokeqt.so.1 (0xb7b1d000)
libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0xb7431000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb740c000)
libz.so.1 => /usr/lib/libz.so.1 (0xb73f8000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb73e9000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb73e0000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb73c9000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb73b7000)
libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0xb7339000)
libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0xb72d5000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7209000)
libc.so.6 => /lib/tls/libc.so.6 (0xb70d1000)
/lib/ld-linux.so.2 (0x80000000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6ff6000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6feb000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6fbc000)
libaudio.so.2 => /usr/lib/libaudio.so.2 (0xb6fa6000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb6f57000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6f4f000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb6f4b000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6f42000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xb6f2f000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6ec2000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb6ebd000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb6e03000)
libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0xb6dfe000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6dde000)
That warning gave me the idea to look at 'ldd /usr/lib/libqt-mt.so.3':
ldd /usr/lib/libqt-mt.so.3
linux-gate.so.1 => (0xffffe000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb784c000)
libaudio.so.2 => /usr/lib/libaudio.so.2 (0xb7837000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb77e8000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb77c3000)
libz.so.1 => /usr/lib/libz.so.1 (0xb77af000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb77a6000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb77a2000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7799000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xb7786000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7719000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb770b000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb763f000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7636000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb761f000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb761b000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7609000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb754f000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7528000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb751d000)
libc.so.6 => /lib/tls/libc.so.6 (0xb73e5000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb73c5000)
/lib/ld-linux.so.2 (0x80000000)
Sorry for the copious output.
Now, in qtruby/rubylib/tutorial/ I can run t1, t2, and t3 just fine,
but t4 gives me an empty gray box. I stuck a puts 'foo' just after the
call to super in t4.rb (line 10), and it seems that it never gets
printed. So it looks like the call to Qt::Widget::initialize via super
is not returning. If I put 'puts "foo"' before the super call, it does
happen.
Hans Fugal
the double libstdc++ stuff. I'm sure it was a bad thing that I was
compiling qtruby with g++ 4.0 and qt had been compiled with 3.3. I've
ironed all of that out now, qt and qtruby and smoke and everything has
been compiled with g++ 4.0. Unfortunately that didn't fix the problem.
:(
Here's the new ldd of qtruby.so:
$ ldd /usr/local/lib/site_ruby/1.8/i386-linux/qtruby.so
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7f0b000)
libsmokeqt.so.1 => /usr/local/lib/libsmokeqt.so.1 (0xb7ab5000)
libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0xb72d3000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb72ae000)
libz.so.1 => /usr/lib/libz.so.1 (0xb729a000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb728b000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7282000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb726b000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7259000)
libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0xb71db000)
libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0xb7177000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb70ab000)
libc.so.6 => /lib/tls/libc.so.6 (0xb6f73000)
/lib/ld-linux.so.2 (0x80000000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6e99000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6e8e000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6e5f000)
libaudio.so.2 => /usr/lib/libaudio.so.2 (0xb6e49000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb6dfa000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6ddc000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb6dd4000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6dcc000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb6dc8000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6dbf000)
libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1
(0xb6dbb000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xb6da8000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6d3b000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb6d37000)
libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0xb6d32000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6d11000)
Hans Fugal
libqt0-ruby1.8 package:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335876 which I did not
realize was the same bug at first, until I had done my puts test.
I'm going to send a link to this discussion to that debian bug and
carry on there.
Hans Fugal
Adeodato Simó
* Richard Dale [Monday, October 31, 2005 08:22] {comp.lang.ruby}:
> Maybe regenerate and rebuild the Smoke library against the Qt 3.3.4
> headers. It has a version of '4:3.3.2-1' which sounds like it was
> generated against the Qt 3.3.2 headers, which would be too old. Change to
> the qtruby/smoke/qt directory and type 'make clean; make' to rebuild the
> library, then install it.
The 3.3.2 there makes reference to the version of KDE that smoke came from
(in the kdebindings module, obviously), not to the version of Qt it was
compiled against.
FWIW, this that Hans report is reproducable for me with libsmokeqt and
qtruby as shipped in KDE 3.4.2, compiled against Qt 3.3.5. (Tested using
the Debian packages in the unstable branch, which I uploaded.) I can't
really thing of un-standard procedures when preparing these packages.
Cheers,
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Richard Dale
I've never had an error where the second puts in this code is never
executed, as described in the bug report:
require 'Qt'
class ConfigDatabase < Qt::Dialog
def initialize(*k)
puts("init in CD")
super(*k)
puts("after Qt::Dialog's init")
end
end
$app = Qt::Application.new(ARGV)
cd = ConfigDatabase.new
In the QtRuby constructor code, it throws an exception after getting part of
the way through constructing the instance, and tries again. This means that
the first puts will actually get executed twice. Normally this doesn't
matter as there isn't any code before the super call in the initialize()
method.
QtRuby used to callcc() to jump out of the constructor, instead of using an
exception. It looks to me as though that change has somehow got messed up
in the debian version.
-- Richard
Hans Fugal
> exception. It looks to me as though that change has somehow got messed up
> in the debian version.
Well, except I first had the problem in the original tarballs (1.0.9
and 1.0.10) that I had downloaded from rubyforge, and then noticed that
the debian package was behaving the same way and that someone had
opened a bug report on it. So it seems it must be the way it interacts
with something on a Debian system.
The bit about repeating stuff worries me. I had no idea everything
before super would be executed twice (but sure enough that seems to be
the case on my laptop - I think it's instructive that on our debian
systems it only prints 'init in CD' once). Is calling super first a
rule in ruby that I somehow missed, or an assumption that either needs
to be changed or trumpeted from the rooftops?
Richard Dale
>> QtRuby used to callcc() to jump out of the constructor, instead of using
>> an exception. It looks to me as though that change has somehow got messed
>> up in the debian version.
>
> Well, except I first had the problem in the original tarballs (1.0.9
> and 1.0.10) that I had downloaded from rubyforge, and then noticed that
> the debian package was behaving the same way and that someone had
> opened a bug report on it. So it seems it must be the way it interacts
> with something on a Debian system.
I would be surprised if QtRuby 1.0.9 and 1.0.10 had this problem.
What happened was that I committed a fix for the 'polluted namespace' bug in
QtRuby, and at the same time I fixed the way callcc() was giving a
confusing stack trace in KDevelop by replacing it with throwing an
exception. The Debian maintainer asked which parts of the commit were for
the namespace problem, and then backported them to the Debian sources. I
think whats happened is that part of the callcc() fix was wrongly applied.
> The bit about repeating stuff worries me. I had no idea everything
> before super would be executed twice (but sure enough that seems to be
> the case on my laptop - I think it's instructive that on our debian
> systems it only prints 'init in CD' once). Is calling super first a
> rule in ruby that I somehow missed, or an assumption that either needs
> to be changed or trumpeted from the rooftops?
Is it possible to have a look at the Qt.cpp and qtruby.rb sources from the
Debian release, and I will be able to tell what's going on? Here is what
the code looks like that uses exceptions. Can you see what these methods
look like in the Debian version?
From Qt.cpp:
static VALUE
initialize_qt(int argc, VALUE * argv, VALUE self)
{
...
free(temp_stack);
// Off with a longjmp, never to return..
rb_throw("newqt", result);
/*NOTREACHED*/
return self;
}
From qtruby.rb:
def Internal.try_initialize(instance, *args)
initializer = instance.method(:initialize)
catch "newqt" do
initializer.call(*args)
end
end
-- Richard
Hans Fugal
> Hans Fugal wrote:
>
> >> QtRuby used to callcc() to jump out of the constructor, instead of using
> >> an exception. It looks to me as though that change has somehow got messed
> >> up in the debian version.
> >
> > Well, except I first had the problem in the original tarballs (1.0.9
> > and 1.0.10) that I had downloaded from rubyforge, and then noticed that
> > the debian package was behaving the same way and that someone had
> > opened a bug report on it. So it seems it must be the way it interacts
> > with something on a Debian system.
>
> I would be surprised if QtRuby 1.0.9 and 1.0.10 had this problem.
Nevertheless, that's what I've been saying. The "empty-window, super
doesn't return" problem happens on Debian etch using qtruby 1.0.9. Make
no mistake about it, every bit of qtruby is what I got directly from
rubyforge. It just so happens that it is also happening with the debian
package. What's more, the very installation of qtruby 1.0.9 (from
source)that was working just fine simply stopped working when I upgraded
to etch, even though qtruby itself did not change.
So what did change? Well libqt3-mt upgraded slightly to 3.3.5 from 3.3.4
(IIRC), ruby went to 1.8.3 from 1.8.2, and (not that it sould matter,
but for completeness) automake is at verson 1.7.9.
> Is it possible to have a look at the Qt.cpp and qtruby.rb sources from the
> Debian release, and I will be able to tell what's going on? Here is what
> the code looks like that uses exceptions. Can you see what these methods
> look like in the Debian version?
Sure, you can find the source at
http://packages.debian.org/unstable/source/kdebindings
Or, you can browse it here: http://hans.fugal.net/tmp/qtruby
> From Qt.cpp:
>
> static VALUE
> initialize_qt(int argc, VALUE * argv, VALUE self)
> {
> ...
>
> free(temp_stack);
> // Off with a longjmp, never to return..
> rb_throw("newqt", result);
> /*NOTREACHED*/
> return self;
> }
Looks the same.
> From qtruby.rb:
>
> def Internal.try_initialize(instance, *args)
> initializer = instance.method(:initialize)
> catch "newqt" do
> initializer.call(*args)
> end
> end
Yes, plus a bit about redefining inspect and pretty_print.
Richard Dale
>
> This time I noticed this at the end of make install:
> /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/lib/libqt-mt.so,
> may conflict with libstdc++.so.6
This looks like the cause of the problem to me.
-- Richard
Hans Fugal
It looked like it might be to me too, but I have since fixed this
problem (got everything compiled by g++ 4.0) and it still happens.
Caleb Tennis
1.8.4_pre1. It seems to work find with fine with Ruby 1.8.3.
http://bugs.gentoo.org/show_bug.cgi?id=111707
Hans Fugal
forgetting the libruby1.8 package for all you debian users) and
rebuilding qtruby (1.0.9 from source), it works like a charm.
If the report is that it works on 1.8.3, I reply that when I had 1.8.3
from Debian installed and did ruby --version, it told me it was version
1.8.4. There's probably some backporting voodoo in the debian
1.8.3-[23] packages that includes whatever is causing the problem.