| Appendix . Appendices | ||
|---|---|---|
 |  | |
| Appendix . Appendices | ||
|---|---|---|
| | | |
This section is dedicated to illustrate and justify some of the options used and fixed by default in the compilation of the Geant4 toolkit. It is also meant to be a simple guide for the user/installer to avoid or overcome problems which may occur on some compilers. Solutions proposed here are based on the experience gained while porting the Geant4 code to different architectures/compilers and are specific to the OS's and compiler's version valid at the current time of writing of this manual.
Detailed instructions for building and installing Geant4, and for building user applications, are found in the Geant4 Installation Guide.
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 performant and more or less optimised, depending on several factors also related to the system architecture which it applies to.
Strict ISO/ANSI compilation is forced (-pedantic and
relevant -std= compiler flags), and code is compiled with
high warning diagnostics (-Wall flag). The default
optimisation level is -O2.
The CMake build mode RelWithDebInfo allows for an
optimised build of the libraries but including debug symbols
(-O2 -g flags on g++, flag G4OPTDEBUG
in the GNUMake system).
When built with support for multithreading, additional flags
-DG4MULTITHREADED -ftls-model=initial-exec -pthread
are used in all build modes. This requires the compiler to support
thread local storage.
Adoption of C++11 standard can be enabled on compilers supporting it,
by specifying c++11 in the relevant configuration
setup option. In this case the flag -DG4USE_STD11
is added for compilation.
Additional compilation options (-march=XXX
-mfpmath=sseYYY) to adopt chip specific floating-point
operations on the SSE unit can be activated by adapting the
XXX, YYY options to your chip and adding these
to the CMAKE_CXX_FLAGS variable via
ccmake or the CMake GUI (or by uncommenting the
relevant part in the Linux-g++.gmk configuration
script for the GNUMake system).
By doing so, a greater stability of results has been verified,
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. Note that
binaries built using these chip-specific options
will likely NOT be portable; generated applications
will only run on the specific chip-based architectures.
Since version .NET 7.0 of the compiler, ISO/ANSI compliance is required.
The setup adopted for the clang compiler on Mac OS X
resembles in most parts the one for Linux systems. Clang
must be used as the Apple supplied GNU/gcc library
does not provides the required level of multithreading support.
When built with support for multithreading, additional flags
-DG4MULTITHREADED -ftls-model=initial-exec -pthread
are used in all build modes
Dynamic libraries (.dylib) are built by default.
The installation of Geant4 sets the install name of the libraries
to the absolute path to the library. Applications linked against the
Geant4 libraries should therefore find the libraries automatically.
Use of an absolute install name means that the Geant4 libraries are
not relocatable without using install_name_tool
to modify the install name and paths to dependent libraries.
| | | |
| 10.5. Novice Examples |  | 2. Histogramming |