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> |
---|