Geant4 User's Guide For Application Developers Appendix

10.1 Tips for Program Compilation

It's well known that each compiler adopts its own internal techniques to produce the object code, which in the end might be more or less perfomant and more or less optimised, depending on several factors also related to the system architecture which it applies to. A peculiarity of C++ compilers nowadays is the way templated instances are treated during the compilation/linkage process. Some C++ compilers need to store temporarily template instantiation files (object files or temporary source code files) in a "template repository" or directory that can be specified as unique or not directly from the compilation command (probably historically coming from the old cfront-based implementation of the C++ compiler).

After the installation of the libraries, we strongly suggest to always distinguish between the installation directory (identified by $G4INSTALL) and the working directory (identified by $G4WORKDIR), in order not to alter the installation area for the template repository.

In Geant4, the path to the template repository (for those compilers which make use of it) is specified by the environment variable $G4TREP, which is fixed and points by default to $G4WORKDIR/tmp/$G4SYSTEM/g4.ptrepository/, where $G4SYSTEM identifies the system-architecture/compiler currently used and $G4WORKDIR is the path to the user working directory for Geant4.

A secondary template repository $G4TREP/exec is created by default and can be used when building executables to isolate the main repository used for building the libraries in case of clashes provoked by conflicting class-names. This secondary template repository can be activated by defining in the environment (or in the GNUmakefile related to the test/example to be built) the flag G4EXEC_BUILD; once activated, the secondary repository will become the read/write one, while the primary repository will be considered read-only.

At the current time, only few compilers still make use of a template repository. A good recommendation valid in general such compilers is to make use of a single template repository (specified by the $G4TREP environment variable) for building all Geant4 libraries; then use a secondary template repository ($G4TREP/exec, together with the $G4EXEC_BUILD flag) when building any kind of example or application.
It's always good practise to clean-up the secondary template repository from time to time.

OS: SunOS
Compiler: CC

The default optimisation level is -O2.
Since version 5.0 of the compiler, native-STL is supported and ISO/ANSI compliance is required.

OS: Linux
Compiler: GNU/gcc

Strict ISO/ANSI compilation is forced (-ansi -pedantic compiler flags), also code is compiled with high verbosity diagnostics (-Wall flag). The default optimisation level is -O2.
NOTE:
Additional compilation options (-march=pentium4 -mfpmath=sse) to adopt Pentium4 chip specific floating-point operations on the SSE unit, can be activated by uncommenting the relevant part in the Linux-g++.gmk configuration script. By doing so, it has been verified a greater stability of results, making possible reproducibility of exact outputs between debug, non-optimised and optimised runs. A little performance improvement (in the order of 2%) can also be achieved in some cases. To be considered that binaries built using these chip-specific options will NOT be portable cross platforms; generated applications will only run on Pentium4-based architectures.

Since version .NET 7.0 of the compiler, ISO/ANSI compliance is required.
See section 3.1 of the Installation Guide for more detailed information.
See also section 10.6 for more tips.

The setup adopted for the g++ compiler on MacOS resembles in great part the one for Linux systems.
The default optimisation level in this case is -O2.
Dynamic libraries (.dylib) are supported as well; once built, in order to run the generated application, the user must specify the absolute path in the system where they're installed with the DYLD_LIBRARY_PATH system variable.