QtRoot problems

ROOT
1

I am trying to get Qtroot going, and I encounter some problems (on SL4):

using qmake on the bnl simple histogram browser from Valeri Fine, it doesn’t find libQtGui.so (In fact, there is no libQtGui anywhere on my system), so I get the message

So I think this means I don’t have “ROOT Qt extensions” installed. (The example does compile, and run, but it starts root and runs as a sub-process- is this how it always works, even if I get Qt extensions installed properly? This would not be desirable for my purposes.)

OK, so I got the source from cvs (cvs -d :pserver:cvsuser@cvs.bnl.gov:/data01/CVS co -Pd qtRoot root), and did qmake from within qtRoot (with – export QTROOTSYSDIR=$ROOTSYS declared in my .bashrc). Now, when I do the ‘sudo make install’, I get many occurances of this error:

[quote]make[1]: Entering directory /home/michael/qtRoot/qtthread' qmake -o Makefile qtthread.pro WARNING: Failure to find: QtThreadDict.cxx make[1]: Leaving directory /home/michael/qtRoot/qtthread’
make[1]: Entering directory /home/michael/qtRoot/qtthread' /usr/root/bin/rootcint -f QtThreadDict.cxx -c -DQT_VERSION=0x30000 -I/usr/lib/qt-3.3/mkspecs/default -I. -Isrc -Iinc -I/usr/root/include -I"/usr/root/include" -I"/usr/root/include" -I/usr/lib/qt-3.3/include -I.ui/ -I.moc/ inc/TQtCondition.h inc/TQtMutex.h inc/TQtThreadFactory.h inc/TQtThreadImp.h inc/LinkDef.h /usr/root/bin/rootcint: error while loading shared libraries: libCint.so: cannot open shared object file: No such file or directory make[1]: *** [QtThreadDict.cxx] Error 127 make[1]: Leaving directory /home/michael/qtRoot/qtthread’
[/quote]
This error is generated by make from nearly every directory in qtRoot. So is this a problem with root itself? It seems that rootcint can’t find libCint.so. But everything else about root seems to work, including the stand-alone root applications (i.e. compile with g++, and run natively) I have written. There must be a flag that is not getting passed, or an environment variable that needs to be set, what could it be?

2

I am expecting that Valeri Fine will process your message once he has recovered from the Russian New Year ::slight_smile:

Rene

3

[quote=“brun”]I am expecting that Valeri Fine will process your message once he has recovered from the Russian New Year ::slight_smile:

Rene[/quote]I am sorry I missed the post :blush: . Shall reply tomorrow :unamused:

4

The first things first.

Where your ROOT comes from?
What is your ROOT version?
Where your Qt comes from?

Please, submit this information (may be privately to fine@bnl.gov )
I would appreciate the log file of your QtRoot installation session and the list of all env variables as well.

Thank you, Valeri

5

[quote=“mrogers”] So is this a problem with root itself? It seems that rootcint can’t find libCint.so. But everything else about root seems to work, including the stand-alone root applications (i.e. compile with g++, and run natively) [/quote]Did you do setenv LD_LIBRARY_PATH $ROOTSYS/lib:$LD_LIBRARY_PATH ?

6

deleted

7

Hi Valeri,

I updated the KDE version in sl4 to 3.5.8 (for other reasons from this problem), It seems to have updated Qt to version 3.3.7 in the process, judging by the output form qmake -v, and the ‘help->about Qt’ menu item in designer. I have been using kdevelop and qt designer without problems since the update, i.e. everything I’ve written since then compiles and runs as I would expect it to, qt widgets do their job, etc.

To answer these questions:

Root is installed from source, which I got from the cern root website.
Root version is 5.16.
Qt is version 3.3.7, which seems to be updated from the version natively in sl4, that is to say, it still resides in /usr/lib/qt-3.3/. Some of the sub-directories show old modify dates, some show the date I did the KDE update.

my environment variables:

I just did a make clean, qmake, and sudo make install in the QtRoot dir, here is the output-

qmake:

sudo make install:
(see attached file)

It looks like rootcint still can’t find libCint.
qtrootLog.txt (25 KB)

8

The lines:

[code]/usr/root/bin/rootcint -f QtRootDict.cxx -c -DQT_VERSION=0x30000 -I/usr/lib/qt-3.3/mkspecs/default -I. -Iinc -I…/qt/inc -I"/usr/root/include" -I"/usr/root/include" -I/usr/lib/qt-3.3/include -I.ui/ -I.moc/ inc/TQtRootGuiFactory.h inc/LinkDef.h

/usr/root/bin/rootcint: error while loading shared libraries: libCint.so: cannot open shared object file: No such file or directory
[/code]indicates that you still have some problem with your vanilla ROOT installation.

To understand where your problem comes from

  1. Can you invoke /usr/root/bin/rootcint from your shell prompt directly, with no Qt / make / qmake / shell scripts whatsoever ?
  2. Can you check the output of the commadldd /usr/root/bin/rootcint 3. Can you check the output of the commadwhich rootcint 4. Can you use ROOT ACliC?
  3. Can you try ls $ROOTSYS/lib/libCint.so
9

Yes, rootcint invokes from a shell (and gives the usage message)
2.

Pretty sure it works, I can do .L nameOfScript.C+ and things go smoothly, loaded functions run in the interpreter, etc.

4

10

Wierd :open_mouth: Can you grant me a remote access to your machine (send me private mail please) ?

11

Hmm… not possible, there is no hole in the firewall for it.

The original problem was that qmake gives me

when I run it on your simple histogram example. It still gets compiled when I do make on it, and executes as well. It just invokes the root interpreter when I run it. This could be ok, if the interpreter is handling only the gui parts, and any computationally intensive code is still running as compiled c++ code, rather than going through cint, which was my only concern. I don’t want the slow down. If there is an instance of cint running, I don’t mind in principle.

So, my question is now, does cint handle everything, or just the GUI?

What’s the difference between the Qt-Extension and Qt-Layer paradigms in this context? I really don’t mind abandoning this line of troubleshooting if I can still crunch numbers at full speed using the system the way it is presently.

Another, slightly unrelated question (Maybe I should start an entirely different thread?):

I like using kdevelop, with qt designer. But, a kdevelop project created from the stock designer based kde application template has no associated .pro file into which I can include rootcint.pri. In fact, it does not seem to use qmake at all, though it does use the qt ‘User Interface Compiler’ (/usr/lib/qt-3.3/bin/uic). Is there a way to use the TQtWidget without qmake so I can use the kedevelop project for writing my applications? Or maybe a different kind of kdevelop project I should use?

Thank you Valeri :slight_smile:

12

[quote=“mrogers”]Hmm… not possible, there is no hole in the firewall for it.

The original problem was that qmake gives me

[quote]
Project MESSAGE: No ROOT Qt Extension was found. Use Qt-layer instead
[/quote][/quote]

This is Ok. That concrete example does not require any “Extension” . One may regard it as a “warning”[quote=“mrogers”]
when I run it on your simple histogram example. It still gets compiled when I do make on it, and executes as well. It just invokes the root interpreter when I run it. This could be ok, if the interpreter is handling only the gui parts, and any computationally intensive code is still running as compiled c++ code, rather than going through cint, which was my only concern. I don’t want the slow down. If there is an instance of cint running, I don’t mind in principle.

So, my question is now, does cint handle everything, or just the GUI?[/quote] I am afraid I did not understand the question, especially the clause “the interpreter is handling only the gui parts”. Let’s go to the next part of your question (below)

[quote=“mrogers”]
What’s the difference between the Qt-Extension and Qt-Layer paradigms in this context?[/quote] There is NO DIFFERENCE as soon as the native compiler via CINT is concern.
The difference is the extent of use of Qt. For example, the Qt-layer provides the Qt-base backend to embed into Qt GUI the TCanvas objects only. Qt-Extension provides the Qt-backend for the ROOT “Context Menu” (and the other components) as well etc. Either has nothing to do with the compiled vs the interpreted mode.

Another, slightly unrelated question (Maybe I should start an entirely different thread?):

I like using kdevelop, with qt designer. But, a kdevelop project created from the stock designer based kde application template has no associated .pro file into which I can include rootcint.pri. In fact, it does not seem to use qmake at all, though it does use the qt ‘User Interface Compiler’ (/usr/lib/qt-3.3/bin/uic). Is there a way to use the TQtWidget without qmake so I can use the kedevelop project for writing my applications? [/quote]
root.bnl.gov/QtRoot/QtRoot.html#kdesigner

[quote=“mrogers”]Or maybe a different kind of kdevelop project I should use?
[/quote]Yes. Just remember that TQtWidget is the QWidget subclass and use it treat it this way . What essentially those *pri files do for you. They do define the $ROOTSYS/include file and the do define the list of the ROOT / QtRoot shared libraries you should link against. The same effect can be achieved with no project file at all see QtRoot/qtExamples/HelloWord/HelloWord.csh
May be it is not a big deal to add this information into your makefile /project by hand. The script in question is one line shell command:g++ `root-config --cflags --glibs` -I$QTDIR/include -L$QTDIR/lib -lqt-mt HelloWord.cxx -o HelloWord

13

Thanks, I’ll have a look in QtRoot/qtExamples/HelloWord/HelloWord.csh. You will probably get more questions from me tomorrow :slight_smile:

Thanks again,
Michael

14

[quote=“mrogers”]Thanks, I’ll have a look in QtRoot/qtExamples/HelloWord/HelloWord.csh. You will probably get more questions from me tomorrow :slight_smile:[/quote]You are welcome :smiley:
I would like to call your attention to the fact that each Qt-Extension can be built TWO ways: with “qmake / make” from the Qt project file provided for each Qt Extension package and with the “normal” make with the Makefile (see Module.mk file) provided for each package also. What you need is to evaluate those Module.mk’s to see how you can adjust it to meet your needs.

15

OK, I’ve got root including correctly, just using root-config --cflags --glibs as cflags in kdevelop. I can instantiate TH1, fill it, ask it what’s inside, etc.

I try to get TQtWidget working: I add -I$QTDIR/include -L$QTDIR/lib -lqt-mt to cflags, but it doesn’t seem to be so simple. If I put a TQtWidget into my designer .ui and build, it complains of "forward declaration of struct TQtWidget' " in my wdigetbase.h file (generated by the kdevelop/Qt layer), and then invalid use of udefined typestruct TQtWidget’. I don’t know what it wants before it will function.

Looking at the makefile from the histogram Qt designer example you wrote, It seems there are a lot of things going on behind the scenes. I am just about ready to give up and abandon the use of root drawing capabilities :frowning: and just use the root math functionality, with Qwt or something for the plotting. Too many hours have been spent in vain now :confused: it’s time to get back to my actual project…

16

[quote=“mrogers”]I try to get TQtWidget working: I add -I$QTDIR/include -L$QTDIR/lib -lqt-mt to cflags, but it doesn’t seem to be so simple. If I put a TQtWidget into my designer .ui and build, it complains of "forward declaration of struct TQtWidget' " in my wdigetbase.h file (generated by the kdevelop/Qt layer), and then invalid use of udefined typestruct TQtWidget’. I don’t know what it wants before it will function. …[/quote]To do what you want, you should first read and follow either “Qt3 Designer” or “KDevelope” or “QtRoot Web site” or “ROOT” manuals. All of them are telling you one and the same thing, “To used the custom widget (and TQtWidget is the custom Qt widget) with the Qt3 designer one has to provide the “Custom Widget” definition. This is the Qt3 rules.
See doc.trolltech.com/3.3/designer-manual-7.html

[quote=" doc.trolltech.com/3.3/designer-manual-7.html"]
Adding the Custom Widget to Qt Designer
Click Tools|Custom|Edit Custom Widgets to invoke the Edit Custom Widgets dialog.
[ul]1. Click New Widget so that we are ready to add our new widget.
2. Change the Class name from ‘MyCustomWidget’ to ‘Vcr’.
3. Click the ellipsis (…) button to the right of the Headerfile line edit to invoke the file Open dialog. Locate vcr.h, select it, and click Open. It will now appear as the header file.
4. If you have a pixmap that you want to use to identify your [/ul]widget on the toolbar click the ellipsis button to the right of Pixmap property. (The ellipsis button appears when you click in the Value part of the Properties list by a pixmap or iconSet property.)
In our example we have the file qt/tools/designer/examples/vcr/play.xpm which we’ll use for this purpose.
5. Since we know the minimum sensible size for our widget we’ll put these values into the Size Hint spin boxes. Enter a width of 80 (in the left hand spin box), and a height of 20 (in the right hand spin box). …[/quote]see ftp://root.cern.ch/root/doc/26ROOTandQt.pdf page 427[quote=“ROOT User’s Guide v5.16”]
Using Qt “Designer” to Create Qt GUI with Embedded ROOT Objects
Qt package is equipped with Qt designer –. . . .
configure Qt designer to use the so-called “custom widget” defined by $ROOTSYS/include/TQtWidget.cw.
The file defines the custom TQtWidget Qt widget to back the embedded TCanvas objects. To customize your
designer start designer and select “Edit Custom Widget” menu: …[/quote][quote=“mrogers”] and then invalid use of udefined type `struct TQtWidget’. I don’t know what it wants before it will function. …[/quote]This message comes from the C++ compiler. It (C++ compiler) wants to see the C++ class definition. This is the C++ language rule. It has nothing to do with Qt / Root / QtRoot. It ( C++ compiler) wants to see TQtWidget.h header file. Qt3 documentation tells you how to do that for any custom widget (it uses vcr class and “vcr.h” header file as an example). ROOT document is explicit about the very TQtWidget class.[quote=“mrogers”]Looking at the makefile from the histogram Qt designer example you wrote, It seems there are a lot of things going on behind the scenes. I am just about ready to give up and abandon the use of root drawing capabilities :frowning: and just use the root math functionality, with Qwt or something for the plotting…[/quote]
This is up to you. However, let me call your attention that your problem comes from misunderstanding of the very Qt3 rules rather from ROOT or QtROOT. This suggests you are going to face the problem you described over and over again as long as you are keeping working with Qt3.

[quote=“mrogers”] Too many hours have been spent in vain now :confused: it’s time to get back to my actual project…[/quote]Hmm, How many hours did you spend reading Qt3 designer Manuals and other related documents :unamused:
Anyway, I am still willing to spend my time to spare you 10 min of reading the manuals. If you still need me to help you to build the correct Qt3 application, send me your code to review. (It may may or may not contain the embedded TCanvas. First things should go first. One has to learn how to create the pure Qt3 applicaition, first.

17

No, you are wrong about me :frowning: , I am reading docs a lot. My effort to learn to use Qt with kdevelop has been successful so far, and I was able to get it to use root classes as well. It is only when I try to tie in TQtWidget that it breaks. I am new at Qt, but I am at least mid-level at c++ and using gcc(++) and make. I can use the root gui classes successfully doing everything by hand in a text editor and writing my own make file. I just wanted to move on and start using designer, since I like the idea of removing the tedious task of coding lots of buttons etc.

Hmm… I did read that actually… I have not been successful in finding anything in the docs that gets me closer to understanding what I need to do.

Does the inclusion of TQtWidget.cw into designer not take care of this definition, as far as using designer is concerned? I guess not, since it doesn’t work… I check it in tools|custom|edit custom widgets, all the slots and signals are defined, and make sense. The header file field points to where the header actually is.

The first thing I did in this process was import TQtWidget as per these instructions. It works in your histogram example. But for my project, I just get these errors. I admit, the way Qt ties all these elements together is still mostly a black box to me. I am trying to understand it.

I just discovered the .ui directory in your histogram example (I didn’t look for hidden files in there until now). The files in there seem to be equivalent to what kdevelop is generating as my widgetbase.[cpp h] files. But yours have lots of includes, mine don’t have many.

But I do read the docs, it’s not always obvious what pieces to read. Much of the time I spend is in searching docs, to the point where it starts to become confusing. I need to concretely implement things, a little bit at a time, and then read things again, or read more things. All steps in teaching myself to use Qt with kdevelop have been solvable and understandable, until now. I don’t blindly try things at random…

Yes, well you see, the part that just uses Qt works fine. It is only when I try to tie in the TQtWidget that things break. Is there a .so that I need to link to? Why does the declaration

class TQtWidget;

in the widgetbase.h file give me the "forward declaration of `struct TQtWidget’ " error? All of the other forward declarations in that file are happily processed by gcc. I have not found the missing pieces. If I can get it to load the definition of TQtWidget, that would be a good step.

Do I need to do this explicitly? I have not been able to identify the mehcanism you are using to do this in your example.

Well, it’s getting a bit late here, I should go home and get back to this tomorrow. I have attached my project. If you delete the TQtWidget from the file proj_0widgetbase.ui, it compiles and runs for me. With that widget pasted onto one of the tabs in my tab container widget, I get the errors.

I do appreciate you spending time with this :slight_smile: Please don’t assume I am too lazy to spend 10 minutes reading docs. I assure you, I have spent much more time than that searching documentation for this. That is always step one, no?
proj_0.zip (1.96 MB)

18

wait.

19

Please find the working version of your project (partly :wink: )
Pleace check the time. I downloaded your file at 16:18 and uploaded the working result at 16:55
It will take me an extra 20 mins to complete it with all features you originally added there.

To build the project

  1. untar
  2. cd src
  3. invoke qmake
  4. invoke make

Please pay your attention to the file size. You uploaded 1.9 Mgb long compressed file. I have uploaded 19K in return
proj0.tar.gz (19.1 KB)

20

Please, find the working version of your project:
This version does pop up the file dialog and fill the histogram on the tab2. the total time to complete your project was 45 min (including 15 min coffee break)
proj0_2.tar.gz (17.9 KB)

proj0.png609×683 18 KB