Rebuilding Geant4 10.7.2

_Geant4 Version:_10.7.2
_Operating System:_Linux Fedora 40
_Compiler/Version:_GNU 14.2.1
_CMake Version:_3.28.2


I am currently running Geant4 11.2.2 on an up to date Fedora 40 OS. However, I am trying to rerun some old simulations done under Geant4 10.7.2 to recheck those results. So I downloaded the source gzipped tar ball from the Geant4 website and carried out the same steps that I had used to install 10.7.2 in 2021, to reinstall it. (I am using the same computer hardware as 2021 and the same OS except the latest version). I used the same options that I had originally used for cmake for Geant4 10.7.2:

$cmake -DGEANT4_BUILD_CXXSTD=14 -DGEANT4_BUILD_MULTITHREADED=ON -DGEANT4_USE_OPENGL_X11=ON -DGEANT4_USE_QT=ON -DGEANT4_INSTALL_EXAMPLES=ON -DGEANT4_INSTALL_DATA=ON -DCMAKE_INSTALL_PREFIX=/home/jmcfee/geant4/geant4-v10.7.2-install /home/jmcfee/geant4/geant4-v10.7.2. 
...this produced lots of output...
Several repeated warnings with:
CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject.cmake:3195 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  /usr/share/cmake/Modules/ExternalProject.cmake:4418 (_ep_add_download_command)
  cmake/Modules/G4InstallData.cmake:408 (ExternalProject_Add)
  cmake/Modules/G4InstallData.cmake:309 (geant4_install_dataset)
  cmake/Modules/G4InstallData.cmake:483 (geant4_configure_datasets)
  cmake/Modules/G4CMakeMain.cmake:67 (include)
  CMakeLists.txt:51 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.
...then lots more output and finally ...
-- Configuring done (5.1s)
-- Generating done (0.6s)
-- Build files have been written to: /home/jmcfee/geant4/geant4-v10.7.2-build

So it seemed to configure successfully if the warnings can be ignored.
Next I did:

$make -j8

First time it failed so I added

#include <cstdint>
to header file /home/jmcfee/geant4/geant4-v10.7.2/source/externals/clhep/include/CLHEP/Random/MixMaxRng.h
Second time failed further along so I made the following 2 changes to /home/jmcfee/geant4/geant4-v10.7.2/source/persistency/ascii/src/G4tgrEvaluator.cc (comment line is original line, (uncommented line is the new one):

//G4double fsqrt(G4double arg) { return std::sqrt(arg); }
G4double fltsqrt(G4double arg) { return std::sqrt(arg); }
//  setFunction("sqrt", (*fsqrt));
    setFunction("sqrt", (*fltsqrt)); 

The change was based on a similar problem from the May 2022 thread Compiling 10.07.p01 on Ubuntu
I then recompiled a third time and linked successully.

Then I did:

$make install

which was successful.

I changed my .bashrc script to point to the 10.7.2 install and checked in a fresh terminal window to see that it actually did so. I then tried to build the B1 example (from the 10.7.2 distribution) to check that the Geant4 version was running OK:

B1_Build]$ cmake -DGeant4_DIR=/home/jmcfee/geant4/geant4-v10.7.2-install/lib64/Geant4-10.7.2 /home/jmcfee/geant4_workdir/10_7_2_2024ed/DistributionExamples/B1
-- The C compiler identification is GNU 14.2.1
-- The CXX compiler identification is GNU 14.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at /home/jmcfee/geant4/geant4-v10.7.2-install/lib64/Geant4-10.7.2/Geant4PackageCache.cmake:19 (geant4_set_and_check_package_variable):
  geant4_set_and_check_package_variable Macro invoked with incorrect
  arguments for macro named: geant4_set_and_check_package_variable
Call Stack (most recent call first):
  /home/jmcfee/geant4/geant4-v10.7.2-install/lib64/Geant4-10.7.2/Geant4Config.cmake:253 (include)
  CMakeLists.txt:16 (find_package)

-- Found EXPAT: /usr/lib64/libexpat.so (found suitable version "2.6.2", minimum required is "2.6.2") 
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Found OpenGL: /usr/lib64/libOpenGL.so   
-- Found X11: /usr/include   
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Configuring incomplete, errors occurred!

I looked up the line in Geant4PackageCache.cmake but I am not sure what the error is referring to or how to fix it. I have attached the more complete Cmake and make outputs for building G4 10.7.2. Any suggestions are welcome.

Output of G410.7.2 Cmake.txt (15.6 KB)
Output of G410.7.2 make.txt (70.6 KB)

The CMake warnings in the initial configure can certainly be safely ignored as they’re just a CMake policy change. As far as I can see your patches to get Geant4 building are fine.

For the build of the application, I would simply go ahead and remove the /home/jmcfee/geant4/geant4-v10.7.2-install/lib64/Geant4-10.7.2/Geant4PackageCache.cmake from the install. It’s safe to do so directly as it will only be used by Geant4Config.cmake if it is present. The only caveat here is if you built Geant4 against any external libraries (e.g. Qt) that are not in system locations, or not pointed to by CMAKE_PREFIX_PATH. If that’s the case, just make sure CMAKE_PREFIX_PATH points to them.

Thank you. That solved the problem.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.