Trouble building on OSF1 with QT layout

Hi rooters

I am trying to build ROOT 5.06 on alpha OSF1 V5.1 with support for QT 3.4.4. QT was built succesfully on the platform (I have tested it).

I succeeded in building ROOT without qt suport, using the platform “alphacxx6” when when I tried to add QT layer support, I got a bunch of error messages like the followings:

cxx -O -tlocal -D__osf__ -D__alpha -Iinclude -long_double_size 64 -DQT_DLL -DQT_THREAD_SUPPORT -I. -I/home/is102438/guillo/QT/QT3/OSF1/include -o qt/src/GQtGUI.o -c qt/src/GQtGUI.cxx
cxx: Error: /usr/lib/cmplrs/cxx/V6.5-014/include/cxx/iosfwd, line 139:
redefinition of default argument
template<class T, class charT = char, class traits=char_traits >

or,

cxx: Error: include/Riosfwd.h, line 25: “istream” has already been declared in the current scope using std::istream;

Does anybody have an idea of what is going on?

Thanks

Hi,

I am not sure where the confusion comes from. To debug this you would need to look at the preprocessed output to see where (and why) the double definition/declaration is coming from.

I.e. you would run:cxx -E -O -tlocal -D__osf__ -D__alpha -Iinclude -long_double_size 64 -DQT_DLL -DQT_THREAD_SUPPORT -I. -I/home/is102438/guillo/QT/QT3/OSF1/include qt/src/GQtGUI.cxx > GQtGUI.EIn the file GQtGUI.E you would look for where istream is declared twice and you would look at the series of line like #line 123 (or #123) filename to see where those file where included from. You also need to go back to the original file to see which #ifdef lead to this situation.

Cheers,
Philippe.

[quote=“matthieuguillo”]Hi rooters

I am trying to build ROOT 5.06 on alpha OSF1 V5.1 with support for QT 3.4.4. QT was built succesfully on the platform (I have tested it).

I succeeded in building ROOT without qt suport, using the platform “alphacxx6” when when I tried to add QT layer support, I got a bunch of error messages like the followings:

cxx -O -tlocal -D__osf__ -D__alpha -Iinclude -long_double_size 64 -DQT_DLL -DQT_THREAD_SUPPORT -I. -I/home/is102438/guillo/QT/QT3/OSF1/include -o qt/src/GQtGUI.o -c qt/src/GQtGUI.cxx
cxx: Error: /usr/lib/cmplrs/cxx/V6.5-014/include/cxx/iosfwd, line 139:
redefinition of default argument
template<class T, class charT = char, class traits=char_traits >

or,

cxx: Error: include/Riosfwd.h, line 25: “istream” has already been declared in the current scope using std::istream;

Does anybody have an idea of what is going on?

Thanks[/quote]

I have no access to OSF1

Can you try to install the Qt layer with Qt “qmake” utility as described
root.bnl.gov/QtRoot/How2Install4 … tallqtroot
to see whether the problem persists.

Thank you

I would like to mention that Qt layer does not use at all :unamused: .
( Did you build your Qt with “stl” support ? )

This suggests, you faced some “side effect”. The problem comes from some clash between iostream defined somewhere inside of Qt and ROOT include files.
You may want to play with the

root.cern.ch/viewcvs/base/inc/Ri … cvs-markup

to see whether it helps.

I mean you can edit the Riostream.h file as follow:

#ifndef ROOT_TGQt using std::istream; using std::ostream; using std::fstream; using std::ifstream; using std::ofstream #endif
or something like this

The investigation suggested by Philippe may help also (Hard to say without any access to your system

Hi Valeri

Yes, I did buid Qt with stl support, just because I like to use STL (std::string instead of QString and the STL containers over QT containers).
I tried to install the QT-Layer from BNL as you suggested, applied qmake and… had the same error messages.

I believe that you are right about the Riostream.h answer and will try it right away.

I will keep you informed

Thanks

[quote=“matthieuguillo”]Hi Valeri
. . .
I believe that you are right about the Riostream.h answer and will try it right away.

I will keep you informed
[/quote]

May I ask you for the simple trick?
Can you add the trouble lines

using std::istream; 
using std::ostream; 
using std::fstream; 
using std::ifstream; 
using std::ofstream 

to some Qt example / tutorial directly and re-build it to see whether the problem will be popped up.

Hi Valeri

I found out it was not related to QT package, but rather to the way cxx uses the iostream files. I tried this simple example:

#include

int main()
{
std::cout << “coucou” << std::endl;
return 0;
}

and at compilation time I had some errors about the std::cout not being in the iostream file.
Now, if I add the macro " -D__USE_STD_IOSTREAM " on the compilation command line then everything is fine.

I tried to add this to the “EXTRA_CXXFLAGS” in the config/Makefile.alphacxx6 but then CINT would not compile! (cf root.cern.ch/root/Cint.phtml?faq) due to the fact that it doesn’t use standard iostream.

My next move is to build everything as before (no QT support), and after it finishes, modifie the EXTRA_CXXFLAGS to add the “-D__USE_STD_IOSTREAM”, rerun configure with QT support and see if it compiles.
This affects also the new Minuit2 package as well as OpenGL support.

I will inform you if it does work.

Cheers

Can you make sure that both ROOT as well as Qt were compiled with

turned on.

ROOT should do this automatically since:
root.cern.ch/viewcvs/base/inc/RC … 83&r2=1.84

Hello Valeri

I will check that QT uses the _USE_STD_IOSTREAM. I am not quite sure, I thought that using the “-stl” flag with configure would do it.

However there is a problem with ROOT somehow: I checked that in the sources I have downloaded (version 5.06) I have the RConfig.h you described. Nethertheless I seemes that when QT support is used, it doesn’t use it. When I force the macro to be defined on the command line, everything works fine!

May be RConfig.h is not used in the qt and qtroot packages and hence the macro _USE_STD_IOSTREAM is not defined?

For now, my problem is fixed, but I had to used the trick I told you: build everything normally without QT support, and then modify the EXTRA_CXXFLAGS Mafefile.alphacxx6 to define _USE_STD_IOSTREAM.

[quote=“matthieuguillo”]Hello Valeri

May be RConfig.h is not used in the qt and qtroot packages and hence the macro _USE_STD_IOSTREAM is not defined?

[/quote]

May I ask you for a favor?

Can you add explicitly

#include "RConfig.h"
as the very fist statement of GQtGUI.cxx followed by all other “includes”? If that that provies a remedy I’ll patch the “root/qt”

On the other hand I expected “qmake” to add this option to the compilation rule. I.e. the sequence “qmake”/ “make” should provide the proper compilation option. The compilation optios are defined by

Can you “grep” the “Makefile” “qmake” creates for the CPP flag in question. If the proper flag is not there then you should have filed the Qt bug report also :wink:

Hi Valeri.
Yes, it does provide a remedy. But I had to do this on every single .cxx file under qt/

[quote/]
On the other hand I expected “qmake” to add this option to the compilation rule. I.e. the sequence “qmake”/ “make” should provide the proper compilation option. The compilation optios are defined by

Can you “grep” the “Makefile” “qmake” creates for the CPP flag in question. If the proper flag is not there then you should have filed the Qt bug report also :wink:[/quote]

I checked that qmake doesn’t create the flag for using STD iostream. That’s bad
:smiling_imp: I will report the bug to the QT team.

Even if you fix the qt package, there is still the problem of OpenGL support wich can be fixed the way I did for QT (not convinent but it works) and the Minuit2 package which has its own configure and for wich I don’t have a solution right now.

Thanks for your help

[quote=“matthieuguillo”]Hi Valeri.
Yes, it does provide a remedy. But I had to do this on every single .cxx file under qt
[/quote]
No, you do not. All Qt sources have to contain (directly indirectly ) “TQtRConfig.h”. It must be sifficient. So what you found is my bug to be fixed.

[quote=“matthieuguillo”]Even if you fix the qt package, there is still the problem of OpenGL support wich can be fixed the way
[/quote]
With the Qt layer ON the OpenGL support comes from Qt also (see: qtRoot/qtgl) and it should be Ok (as soon as the Qt OpenGL tests, and demos, and QtGBrowser example root.bnl.gov/QtRoot/QtRoot.html#designer
root.bnl.gov/QtRoot/root/qtExamp … ser/README
root.bnl.gov/QtRoot/GeomBrowserMain.png
work for you).

I am sorry, this is out my control and you should file the ROOT bug report.
savannah.cern.ch/bugs/?func=add … up=savroot

Hello

I would appreciate you apply the patch below to see whether your problem still persists. The patch is just to move the include “TQtRConfig.h” to the very first position.
Thank you

[code]Index: TGQt.h

RCS file: /data01/CVS/root/qt/inc/TGQt.h,v
retrieving revision 1.45
diff -u -r1.45 TGQt.h
— TGQt.h 10 Jul 2005 00:34:57 -0000 1.45
+++ TGQt.h 1 Dec 2005 01:39:55 -0000
@@ -22,6 +22,8 @@
// //
//////////////////////////////////////////////////////////////////////////

+#include “TQtRConfig.h”
+
#ifndef CINT
#include
#include
@@ -59,8 +61,6 @@

#include “TVirtualX.h”

-#include “TQtRConfig.h”

class TQtMarker;

class TQtPen;
[/code]

Hi Valeri

The fix succeeded to compile GQtGUI.cxx failed on but then failed on GQtGUIThread.cxx. I am not sure to understand why.

[quote=“matthieuguillo”]Hi Valeri

The fix succeeded to compile GQtGUI.cxx failed on but then failed on GQtGUIThread.cxx. I am not sure to understand why.[/quote]

Mt guess, this is because the first include in GQtGUIThread.cxx is
include <qapplication.h> followded by #include “TQtThread.h”. One shoudle invert the order. I.e insated of

[code]#include <qapplication.h>

#include “TQtThread.h”[/code]
try

#include "TQtThread.h" #include <qapplication.h>
to make sure “TQtRConfig” goes first, before any Qt header file is read.