During installation of Qt-GUI the following error occurs using geant4.9.2.p02 and geant4.9.3.b01: ----------------------------------------------------- Autodetection failed to locate Qt3 or Qt4 in on your system. Please enter the path to your Qt3 OR Qt4 install (i.e. if Qt4 is installed in PATH/include/QT, PATH/include or PATH/include/qt4, enter PATH), or type '-' to CANCEL the build of the Qt UI module. Qt path: /usr/share/qt4 checking for qglobal.h... /usr/share/qt4/include/QtCore/qglobal.h checking Qt major version... 4 checking for QtGui headers... yes checking for QtOpenGL headers... yes checking for QtCore library... no checking for moc... /usr/share/qt4/bin/moc Checking /usr/share/qt4/bin/moc major version is 4... yes ----------------------------------------------------- Operating System: Linux-Debian Location of libqt4-core: /usr/lib/libQtCore.so.4 Location of libqt4-dev: /usr/include/qt4/QtCore Best regards, Björn Riese.
I don't quite understand what's going on here. If you have libqt4-core and libqt4-dev installed, then autodetection *should* be o.k. - since it does fail, could you please post the output from it? I didn't think /usr/share was a standard install location for qt4, certainly I'm not aware of any distro installing libraries there, hence the failure to find libQtCore. This looks to be a problem with autodetection in /usr/include or /usr/lib{64}, so to resolve this I need to know what the output of the autodetection is. Cheers, Ben.
(In reply to comment #1) > I don't quite understand what's going on here. > > If you have libqt4-core and libqt4-dev installed, then autodetection *should* > be o.k. - since it does fail, could you please post the output from it? > > I didn't think /usr/share was a standard install location for qt4, certainly > I'm not aware of any distro installing libraries there, hence the failure to > find libQtCore. > > This looks to be a problem with autodetection in /usr/include or /usr/lib{64}, > so to resolve this I need to know what the output of the autodetection is. > > Cheers, > > Ben. Here is the output that I get from version geant4.9.3.b01 and geant4.9.2.p02: briese@lxi002:~/geant4.9.3.b01$ ./Configure -build --- Geant4 Toolkit Build --- Would you like to see the instructions? [n] Definition of G4SYSTEM variable is Linux-g++. That stands for: 1) OS : Linux 2) Compiler : g++ To modify default settings, select number above (e.g. 2) [Press [Enter] for default settings] There exists a config.sh file. Shall I use it to set the defaults? [n] y Fetching default answers from your old config.sh file... I can set things up so that your shell scripts and binaries are more portable, at what may be a noticable cost in performance. In particular, if you ask to be portable, the following happens: 1) Shell scripts will rely on the PATH variable rather than using the paths derived above. 2) ~username interpretations will be done at run time rather than by Configure. Do you expect to run these scripts and binaries on multiple machines? [n] Where is Geant4 source installed? [/u/briese/geant4.9.3.b01] Specify the path where Geant4 libraries and source files should be installed. [/u/briese/geant4.9.3.b01] Do you want to copy all Geant4 headers in one directory? [n] Specify the path where the Geant4 data libraries PhotonEvaporation2.0 RadioactiveDecay3.2 G4EMLOW6.2 G4NDL3.13 G4ABLA3.0 are installed. For now, a flat directory structure is assumed, and this can be customized at the next step if needed. [/u/briese/geant4.9.3.b01/data] checking for PhotonEvaporation2.0... yes checking for RadioactiveDecay3.2... yes checking for G4EMLOW6.2... yes checking for G4NDL3.13... yes checking for G4ABLA3.0... yes Please, specify where CLHEP is installed. It was found in: CLHEP_BASE_DIR: /u/briese/2.0.4.2/CLHEP [/u/briese/2.0.4.2/CLHEP] You can customize paths and library name of you CLHEP installation: 1) CLHEP_INCLUDE_DIR: /u/briese/2.0.4.2/CLHEP/include 2) CLHEP_LIB_DIR: /u/briese/2.0.4.2/CLHEP/lib 3) CLHEP_LIB: CLHEP To modify default settings, select number above (e.g. 2) [Press [Enter] for default settings] By default 'static' (.a) libraries are built. Do you want to build 'shared' (.so) libraries? [n] Do you want to build 'global' compound libraries? [n] Do you want to compile libraries in DEBUG mode (-g)? [n] G4UI_NONE If this variable is set, no UI sessions nor any UI libraries are built. This can be useful when running a pure batch job or in a user framework having its own UI system. Do you want to set this variable ? [n] G4UI_BUILD_XAW_SESSION G4UI_USE_XAW Specifies to include and use the XAW interfaces in the application to be built. The XAW (X11 Athena Widget set) extensions are required to activate and build this driver. [n] G4UI_BUILD_XM_SESSION G4UI_USE_XM Specifies to include and use the XM Motif based user interfaces. The XM Motif extensions are required to activate and build this driver. [n] G4UI_BUILD_QT_SESSION G4UI_USE_QT Setting these variables will enable the building of the G4 Qt based user interface module and the use of this module in your applications respectively. The Qt3 or Qt4 headers, libraries and moc application are required to enable the building of this module. Do you want to enable build and use of this module? [y] checking for qglobal.h... /usr/include/qt4/QtCore/qglobal.h checking Qt major version... 4 checking for QtGui headers... yes checking for QtOpenGL headers... yes checking for QtCore library... no checking for moc... /usr/bin/moc-qt4 Autodetection failed to locate Qt3 or Qt4 in on your system. Please enter the path to your Qt3 OR Qt4 install (i.e. if Qt4 is installed in PATH/include/QT, PATH/include or PATH/include/qt4, enter PATH), or type '-' to CANCEL the build of the Qt UI module. Qt path:
Thanks for the information. It looks like either libQtCore is missing or there's some weirdness going on with the paths. Can you confirm the list of files named libQtCore* in /usr/lib please (I'm assuming this is a 32bit system, but if you have a /usr/lib64, please list the libQtCore files in that directory too)? I've compared on an Ubuntu 8.04 box - not identical, but does have qglobal.h in the same location - which is used to derive the location of the library directory. This works and picks up libQtCore o.k. - suggesting there's something odd going on because if you've got qglobal.h, you should have all the libQtCore files as well... Ben.
(In reply to comment #3) > Thanks for the information. It looks like either libQtCore is missing or > there's some weirdness going on with the paths. > > Can you confirm the list of files named libQtCore* in /usr/lib please (I'm > assuming this is a 32bit system, but if you have a /usr/lib64, please list the > libQtCore files in that directory too)? > > I've compared on an Ubuntu 8.04 box - not identical, but does have qglobal.h in > the same location - which is used to derive the location of the library > directory. This works and picks up libQtCore o.k. - suggesting there's > something odd going on because if you've got qglobal.h, you should have all the > libQtCore files as well... > > Ben. Additional information ...: briese@lxi002:/usr/lib$ ls libQtCore* libQtCore.prl libQtCore.so libQtCore.so.4 libQtCore.so.4.2 libQtCore.so.4.2.1 briese@lxi002:/usr/lib$ cd /usr/lib64 briese@lxi002:/usr/lib64$ ls libQtCore* ls: libQtCore*: No such file or directory briese@lxi002:/usr/lib64$ -------------------------- briese@lxi002:/usr/lib$ locate qglobal.h /usr/include/qt3/qglobal.h /usr/include/qt4/Qt/qglobal.h /usr/include/qt4/QtCore/qglobal.h
O.k., the cause of this problem is that you have no (QtCore) libraries in /usr/lib64 - and Configure will use this directory if it exists. I *think* (though I'm not a Debian expert) that this originates from Debian's slightly different policy on lib vs lib64. As I understand it, on amd64 Debian (which you seem to have?) /usr/lib64 should be a symlink to /usr/lib for compatibility - but that does not seem to be the case on your system (could you confirm?). Things may have changed in their packaging though. In principal this is fixable in Configure if this is the cause, and it'll be quite a hack (platform specific and requires file type queries). It may therefore take some time to implement cleanly. Ben.
(In reply to comment #5) > O.k., the cause of this problem is that you have no (QtCore) libraries in > /usr/lib64 - and Configure will use this directory if it exists. > > I *think* (though I'm not a Debian expert) that this originates from Debian's > slightly different policy on lib vs lib64. As I understand it, on amd64 Debian > (which you seem to have?) /usr/lib64 should be a symlink to /usr/lib for > compatibility - but that does not seem to be the case on your system (could you > confirm?). Things may have changed in their packaging though. > > In principal this is fixable in Configure if this is the cause, and it'll be > quite a hack (platform specific and requires file type queries). It may > therefore take some time to implement cleanly. > > Ben. Indeed, if I use a 32-bit Etch-machine there exists no /usr/lib64 link. If I use Etch64 I'm able to run the ./Configure -build skript. Thanks a lot for your help! Best regards, Björn.
(In reply to comment #6) > (In reply to comment #5) > > O.k., the cause of this problem is that you have no (QtCore) libraries in > > /usr/lib64 - and Configure will use this directory if it exists. > > > > I *think* (though I'm not a Debian expert) that this originates from Debian's > > slightly different policy on lib vs lib64. As I understand it, on amd64 Debian > > (which you seem to have?) /usr/lib64 should be a symlink to /usr/lib for > > compatibility - but that does not seem to be the case on your system (could you > > confirm?). Things may have changed in their packaging though. > > > > In principal this is fixable in Configure if this is the cause, and it'll be > > quite a hack (platform specific and requires file type queries). It may > > therefore take some time to implement cleanly. > > > > Ben. > > Indeed, if I use a 32-bit Etch-machine there exists no /usr/lib64 link. > If I use Etch64 I'm able to run the ./Configure -build skript. > > Thanks a lot for your help! > Best regards, Björn. There must be an error in the configure skript. Despite the fact that my machine is a 32-Bit system there exists a /usr/lib64 directory without link to /usr/lib/libQtCore. If I create a symbolic link "configure" finds the library: ln -s /usr/lib/libQtCore /usr/lib64/libQtCore
The Configure script for Qt in CVS has been updated to support biarch platforms. It will now cross-check that the system really is 64bit if lib64 exists. If it is, lib64 will be used, otherwise lib will be used. It's assumed Geant4 is never cross-compiled through the Configure script.
