I'm attempting to build and run one of my applications on a new HPC platform, which has both the Intel and GCC compilers installed. The platform makes use of LMod module loading for the user to customize their environment, and they have provided Geant4 10.6 as such a module, with the "Intel toolchain." On this system, every module load prepends that module's designated "include" directory to the CPATH envvar. This includes the modules for both the Intel and GCC compilers. Because CPATH is defined, every compiler will search all of the directories in CPATH for #include resolution. My application builds (like the examples) with plain Make, so I source geant4make.sh in my session. This identifies as G4SYSTEM=Linux-icc. When I try to build, the dependency generation (.d files) in binmake.gmk fails with an unexpected error: Making dependency for file src/G4VPhononProcess.cc ... In file included from /sw/eb/software/Geant4/10.6-intel-2019b/include/Geant4/G4Types.hh:71, from /sw/eb/software/Geant4/10.6-intel-2019b/include/Geant4/G4ios.hh:38, from /sw/eb/software/Geant4/10.6-intel-2019b/include/Geant4/globals.hh:48, from /sw/eb/software/Geant4/10.6-intel-2019b/include/Geant4/G4VDiscreteProcess.hh:52, from ./include/G4CMPVProcess.hh:19, from ./include/G4VPhononProcess.hh:18, from src/G4VPhononProcess.cc:16: /sw/eb/software/iccifort/2019.5.281/include/complex:53:3: error: #error "This Intel <complex> is for use only with the Intel C++ compilers!" # error "This Intel <complex> is for use only with the Intel C++ compilers!" ^~~~~ The .d target in binmake.gmk (as well as in common.gmk) has "g++ -M" hardcoded. Because of the CPATH setting (described above), the Intel compiler directories are searched prior to GCC's own directories. Consequently, g++ "resolves" #include <complex> with the Intel version, which triggers the error above. I've reviewed all of the compiler types which Geant4 still supports in the config/sys/ Makefiles: {michaels-mbp:1179} ls $G4INSTALL/config/sys AIX-xlC.gmk HP-aCC.gmk SGI-CC.gmk DEC-cxx.gmk Linux-clang.gmk SUN-CC.gmk Darwin-clang.gmk Linux-g++.gmk WIN32-VC.gmk Darwin-g++.gmk Linux-icc.gmk WIN32-g++.gmk Every one of these compilers is able to do dependency file (.d) generation in Make format. Most of them use the same the "-M" preprocessor option to do that, following GCC's lead. There are two which have a different option flag for the same purpose: HP-aCC uses "+m", and SUN-CC (Solaris by Oracle, now) uses "-xM". I would propose the following small modification to the legacy Makefile system. 1) In binmake.gmk and common.gmk, remove the "GPPFLAGS" variable setting. 2) In binmake.gmk and common.gmk, replace "g++ $(GPPFLAGS)" with "$(CXX) $(DEPFLAGS)". 3) In all of the config/sys/*.gmk files, add a definition "DEPFLAGS := -M", except for the two oddballs above: HP-acc.gmk gets "DEPFLAGS := +m", and SUN-CC.gmk gets "DEPFLAGS := -xM".
As previously discussed offline, the GNUmake system was implemented with the -prerequisite- to use GCC for computing the dependencies, in order to assure portability across platforms. The availability of options on the different compilers to compute the dependencies is unfortunately not the only requirement, as the format of the generated dependency files must be assured to be the -same- in order for the 'liblist' program tool to parse them and generated the dependency tree... The proposed solution was considered and was not possible at the time the system was implemented... Will verify if this can work nowadays on at least the four main platforms/compilers we support (gcc, clang, icc, VC++ on Linux/MacOS/Windows). No guarantees though! Is there any reason why Geant4 is not being installed/used through native CMake configuration (the one we now support) instead of GNUmake?
The alternative (but not recommended as today supported only for "internal" use) is to have an installation of Geant4 done with GNUmake instead of mixing a CMake installation of the toolkit with a GNUmake build of the application. This should implicitly work with no errors.
I understand the concern with common.gmk (the legacy Make build of Geant4 itself). That isn't the specific issue here. When end user applications are built using Make, it is binmake.gmk which is involved. That file _also_ uses the hardcoded "g++ -M" option, and that seems to be where the Intel/GCC collision happens on the particular site. Do the end-user Make builds also use liblist to parse the content of .d?
The implementation in binmake.gmk is coherent with the way dependencies are treated elsewhere in the system, and everything works if an installation made through GNUmake is used through GNUmake. Now, why this fails when mixing with a CMake installation is something that should be eventually understood.
Closing ticket as GNUmake system (and its binding with CMake) is no longer under development.
