[904] | 1 | <!-- ******************************************************** --> |
---|
| 2 | <!-- --> |
---|
| 3 | <!-- [History] --> |
---|
| 4 | <!-- Converted to DocBook: Katsuya Amako, Aug-2006 --> |
---|
| 5 | <!-- --> |
---|
| 6 | <!-- ******************************************************** --> |
---|
| 7 | |
---|
| 8 | |
---|
| 9 | <!-- ******************* Section (Level#1) ****************** --> |
---|
| 10 | <sect1 id="sect.TpPrgCmp"> |
---|
| 11 | <title> |
---|
| 12 | Tips for Program Compilation |
---|
| 13 | </title> |
---|
| 14 | |
---|
| 15 | <para> |
---|
| 16 | This section is dedicated to illustrate and justify some of the |
---|
| 17 | options used and fixed by default in the compilation of the Geant4 |
---|
| 18 | toolkit. It is also meant to be a simple guide for the |
---|
| 19 | user/installer to avoid or overcome problems which may occur on |
---|
| 20 | some compilers. Solutions proposed here are based on the experience |
---|
| 21 | gained while porting the Geant4 code to different |
---|
| 22 | architectures/compilers and are specific to the OS's and compiler's |
---|
| 23 | version valid at the current time of writing of this manual. |
---|
| 24 | </para> |
---|
| 25 | |
---|
| 26 | <para> |
---|
| 27 | It's well known that each compiler adopts its own internal |
---|
| 28 | techniques to produce the object code, which in the end might be |
---|
| 29 | more or less perfomant and more or less optimised, depending on |
---|
| 30 | several factors also related to the system architecture which it |
---|
| 31 | applies to. A peculiarity of C++ compilers nowadays is the way |
---|
| 32 | templated instances are treated during the compilation/linkage |
---|
| 33 | process. Some C++ compilers need to store temporarily template |
---|
| 34 | instantiation files (object files or temporary source code files) |
---|
| 35 | in a "template repository" or directory that can be specified as |
---|
| 36 | unique or not directly from the compilation command (probably |
---|
| 37 | historically coming from the old cfront-based implementation of the |
---|
| 38 | C++ compiler). |
---|
| 39 | </para> |
---|
| 40 | |
---|
| 41 | <para> |
---|
| 42 | After the installation of the libraries, we strongly suggest to |
---|
| 43 | always distinguish between the installation directory (identified |
---|
| 44 | by $G4INSTALL) and the working directory (identified by |
---|
| 45 | $G4WORKDIR), in order not to alter the installation area for the |
---|
| 46 | template repository. |
---|
| 47 | </para> |
---|
| 48 | |
---|
| 49 | <para> |
---|
| 50 | In Geant4, the path to the template repository (for those |
---|
| 51 | compilers which make use of it) is specified by the environment |
---|
| 52 | variable $G4TREP, which is fixed and points by default to |
---|
| 53 | <literal>$G4WORKDIR/tmp/$G4SYSTEM/g4.ptrepository/</literal>, where |
---|
| 54 | <literal>$G4SYSTEM</literal> identifies the system-architecture/compiler |
---|
| 55 | currently used and <literal>$G4WORKDIR</literal> is the path to the user |
---|
| 56 | working directory for Geant4. |
---|
| 57 | </para> |
---|
| 58 | |
---|
| 59 | <para> |
---|
| 60 | A secondary template repository <literal>$G4TREP/exec</literal> is |
---|
| 61 | created by default and can be used when building executables to |
---|
| 62 | isolate the main repository used for building the libraries in case |
---|
| 63 | of clashes provoked by conflicting class-names. This secondary |
---|
| 64 | template repository can be activated by defining in the environment |
---|
| 65 | (or in the GNUmakefile related to the test/example to be built) the |
---|
| 66 | flag <literal>G4EXEC_BUILD</literal>; once activated, the secondary |
---|
| 67 | repository will become the read/write one, while the primary |
---|
| 68 | repository will be considered read-only. |
---|
| 69 | </para> |
---|
| 70 | |
---|
| 71 | <para> |
---|
| 72 | At the current time, only few compilers still make use of a |
---|
| 73 | template repository. A good recommendation valid in general such |
---|
| 74 | compilers is to make use of a single template repository (specified |
---|
| 75 | by the <literal>$G4TREP</literal> environment variable) for building all |
---|
| 76 | Geant4 libraries; then use a secondary template repository |
---|
| 77 | (<literal>$G4TREP/exec</literal>, together with the |
---|
| 78 | <literal>$G4EXEC_BUILD</literal> flag) when building any kind of example or |
---|
| 79 | application. |
---|
| 80 | </para> |
---|
| 81 | |
---|
| 82 | <para> |
---|
| 83 | It's always good practise to clean-up the secondary template |
---|
| 84 | repository from time to time. |
---|
| 85 | </para> |
---|
| 86 | |
---|
| 87 | |
---|
| 88 | <!-- ******************* Section (Level#2) ****************** --> |
---|
| 89 | <sect2 id="sect.TpPrgCmp.UnxLnxGpp"> |
---|
| 90 | <title> |
---|
| 91 | Unix/Linux - g++ |
---|
| 92 | </title> |
---|
| 93 | |
---|
| 94 | <para> |
---|
| 95 | OS: Linux |
---|
| 96 | </para> |
---|
| 97 | |
---|
| 98 | <para> |
---|
| 99 | Compiler: GNU/gcc |
---|
| 100 | </para> |
---|
| 101 | |
---|
| 102 | <para> |
---|
| 103 | Strict ISO/ANSI compilation is forced (<literal>-ansi -pedantic</literal> |
---|
| 104 | compiler flags), also code is compiled with high verbosity |
---|
| 105 | diagnostics (<literal>-Wall</literal> flag). The default optimisation level |
---|
| 106 | is <literal>-O2</literal>. |
---|
| 107 | </para> |
---|
| 108 | |
---|
| 109 | <note> |
---|
| 110 | <title>Note</title> |
---|
| 111 | |
---|
| 112 | <para> |
---|
| 113 | Additional compilation options (<literal>-march=XXX |
---|
| 114 | -mfpmath=sseYYY</literal>) to adopt chip specific floating-point |
---|
| 115 | operations on the SSE unit, can be activated by adapting the |
---|
| 116 | <literal>XXX, YYY</literal> options and uncommenting the relevant |
---|
| 117 | part in the <literal>Linux-g++.gmk</literal> configuration script. |
---|
| 118 | By doing so, it has been verified a greater stability of results, |
---|
| 119 | making possible reproducibility of exact outputs between debug, |
---|
| 120 | non-optimised and optimised runs. A little performance improvement |
---|
| 121 | (in the order of 2%) can also be achieved in some cases. To be |
---|
| 122 | considered that binaries built using these chip-specific options |
---|
| 123 | will likely NOT be portable cross platforms; generated applications |
---|
| 124 | will only run on the specific chip-based architectures. |
---|
| 125 | </para> |
---|
| 126 | </note> |
---|
| 127 | |
---|
| 128 | </sect2> |
---|
| 129 | |
---|
| 130 | |
---|
| 131 | <!-- ******************* Section (Level#2) ****************** --> |
---|
| 132 | <sect2 id="sect.TpPrgCmp.WndMsVslCpp"> |
---|
| 133 | <title> |
---|
| 134 | Windows - MS Visual C++ |
---|
| 135 | </title> |
---|
| 136 | |
---|
| 137 | <para> |
---|
| 138 | OS: MS/Windows |
---|
| 139 | </para> |
---|
| 140 | |
---|
| 141 | <para> |
---|
| 142 | Compiler: MS-VC++ |
---|
| 143 | </para> |
---|
| 144 | |
---|
| 145 | <para> |
---|
| 146 | Since version .NET 7.0 of the compiler, ISO/ANSI compliance is |
---|
| 147 | required. |
---|
| 148 | </para> |
---|
| 149 | |
---|
| 150 | <para> |
---|
| 151 | See <xref linkend="sect.ClassCate" /> of the Installation Guide for |
---|
| 152 | more detailed information. |
---|
| 153 | See also <xref linkend="sect.BldMSV" /> for more tips. |
---|
| 154 | </para> |
---|
| 155 | |
---|
| 156 | </sect2> |
---|
| 157 | |
---|
| 158 | |
---|
| 159 | <!-- ******************* Section (Level#2) ****************** --> |
---|
| 160 | <sect2 id="sect.TpPrgCmp.McXCpp"> |
---|
| 161 | <title> |
---|
| 162 | MacOS-X - g++ |
---|
| 163 | </title> |
---|
| 164 | |
---|
| 165 | <para> |
---|
| 166 | OS: MacOS/Darwin |
---|
| 167 | </para> |
---|
| 168 | |
---|
| 169 | <para> |
---|
| 170 | Compiler: GNU/gcc |
---|
| 171 | </para> |
---|
| 172 | |
---|
| 173 | <para> |
---|
| 174 | The setup adopted for the <literal>g++</literal> compiler on MacOS |
---|
| 175 | resembles in great part the one for Linux systems. |
---|
| 176 | </para> |
---|
| 177 | |
---|
| 178 | <para> |
---|
| 179 | The default optimisation level in this case is <literal>-O2</literal>. |
---|
| 180 | </para> |
---|
| 181 | |
---|
| 182 | <para> |
---|
| 183 | Dynamic libraries (<literal>.dylib</literal>) are supported as well; once |
---|
| 184 | built, in order to run the generated application, the user must |
---|
| 185 | specify the absolute path in the system where they're installed |
---|
| 186 | with the <literal>DYLD_LIBRARY_PATH</literal> system variable. |
---|
| 187 | </para> |
---|
| 188 | |
---|
| 189 | |
---|
| 190 | </sect2> |
---|
| 191 | </sect1> |
---|