version: @@version@@
1. How to build Geant4 on Solaris 11
1.1. Dependencies
1.1.1. cmake
cmake-2.8
is needed but, as of the time of writing, Solaris 11 bundles
cmake-2.6
. Therefore, one needs to install cmake-2.6
with:
pkg install developer/build/cmake
and then use that to bootstrap cmake-2.8
. Finally we use cmake-2.8
to
build Geant4
as per the docs instructions.
export PATH=$PATH:/opt/cmake-2.8/bin
1.1.2. xerces-c
In order to build Geant4
with GDML support (which in turn is needed
if one wants to run the FullCMS
experiment), the xerces-c
library
must be installed. xerces-c
doesn’t exist as binary package at all.
Therefore, we need to build it from sources:
pkg install library/icu # needed as a dependency for xerces-c
pkg install x11/library/mesa # needed by geant4
In the bechmarks/calorimeters/FullCMS/README
file, it is stated that
the version of xerces-c
must be the same as the one used to produce
the cms.gdml
(which is 2.8). xerces-2.8
though, doesn’t seem to build
out of the box, but 3.1.1
does and it is able to parse the gdml file
fine (backwards compatible?).
wget http://apache.cc.uoc.gr//xerces/c/3/sources/xerces-c-3.1.1.tar.gz
export ICUROOT="/usr" # assuming libicu is in /usr/lib/libicu.so
cd xerces-c-3.1.1 && ./configure --prefix=/opt/xerces-c-3.1.1 \
&& gmake && gmake install
![]() |
XERCESC_ROOT_DIR is a -D…=… CMake cache option; not an environmental
variable! |
1.2. Patch needed for Solaris
Solaris 11 seems to leak some symbols in /usr/include/sys/regset.h
, around
line 78
. Later on, while compiling legitimate code in Geant4
, such as:
G4double CA[15] =
{ 8.03768, 9.03104, 10.0169, 11.0114, 12. , 13.0034, 14.0032, 15.0106,
16.0147, 17.0226, 18.0268, 19.0353, 20.0403, 21.0493, 22.0565 };
AddElement("C", 6, 15, *CN , *CA , *CS , *CW);
the build fails, because CS
is substituded, during the preprocessing
stage, with the following:
G4double 15[15] =
{ 25, 23, 4, 10, 0, 10, 4, 9, 4, 19, 30, 12, 22, 54, 97 };
AddElement("C", 6, 15, *CN , *CA , *15 , *CW);
resulting in all kinds of weird errors. How to get the preprocessed source code:
stathis:materials/src% g++ -E -I../../materials/include \
-I../../global/management/include \
-I../../externals/clhep/include \
G4NistElementBuilder.cc
Symbols most likely to clash with geant4’s, directly taken from sys/regset.h:
#define SS 18 /* only stored on a privilege transition */
#define UESP 17 /* only stored on a privilege transition */
#define EFL 16
#define CS 15
#define EIP 14
#define ERR 13
#define TRAPNO 12
#define EAX 11
#define ECX 10
#define EDX 9
#define EBX 8
#define ESP 7
#define EBP 6
#define ESI 5
#define EDI 4
#define DS 3
#define ES 2
#define FS 1
#define GS 0
I had to bisect the problem space by inserting #undef CS
before and after
the inclusion of various header files, starting from the Geant4
specific and
going as far as the system header files.
This is a transitive
patch to workaround the issue. The sol11fix.h
must be included after the
inclusion of every other header file (in the problematic .cc files), i.e.,
be the last header file to be included. Otherwise, the inclusion of some other
header may cause the redefinition of the symbols.
![]() |
I need to properly integrate the patch to not use hardcoded include
paths, e.g., #include "../../../../../global/sol11fix.hh" . Otherwise it
will not work out of the box if one -say- tries to build granular libraries,
by invoking make in $G4INSTALL/source , rather than $G4INSTALL . |
Pere suggested that since the inclusion of sys/wait.h
in stdlib.h
is
guarded by:
#if defined(__EXTENSIONS__) || defined(_XPG4)
#include <sys/wait.h>
#endif
perhaps we could make the issue go away by passing -U__EXTENSIONS__
or -U_XPG4
in g++. This is something that I will soon test.
1.2.1. How to enable the SmartTrackStack
Calling cmake -DG4_USESMARTSTACK …
will not work, because that sets
a CMake cache variable. What we want is to pass a preprocessor macro
in g+. The proper way to do that is to add the following in the +CMakeLists.txt
file:
add_definitions(-DG4_USESMARTTRACKSTACK)
or modify the CMAKE_CXX_FLAGS
variable, again inside the CMakeLists.txt
.
1.2.2. FullCMS
-
fast notes …
export XERCESROOT=/opt/xerces-c...
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:...
setup the environmental variables …
apply the patch http://leaf.dragonflybsd.org/~beket/geant4/fullCMS.diff build granular libraries QUESTION: does GEANT4_BUILD_GRANULAR_LIBRARIES=ON builds ONLY granular libraries or does it build them along with non-granular ?
cd $G4INSTALL/source
gmake
and the libraries should reside at:
After rebuilding geant4 with GDML
support and the installation of
benchmarks/calorimeters/FullCMS and for no apparent reason, Geant4
programs
started to hang. A pstack(1)
on exampleN01
(which has been previously
working fine) returned:
curl http://leaf.dragonflybsd.org/~beket/geant4/pstack.exampleN01 |\
/usr/gnu/bin/c++filt | less
Part of the problem is the call to cxa_guard_acquire()
, which is used
internally by g\
+ to protect the construction of local static variables.
It seems though that cxa_guard_release()
is never get called and the
program just waits indefinetely. I hypothesize that 1) the initialisation
code is thread-safe, but not reentrant-safe and 2) there is a 2nd call
from the same context, possibly due to the construction of some complex
object, which leads to the deadlock. The construction of global static
variables doesn’t pose a problem, as it takes place before any function
of the translation unit gets executed.
UPDATE: It appears that this problem is exhibited when the Debug option
-DCMAKE_BUILD_TYPE=Debug
is set, along with GEANT4_USE_GDML, etc
. A
workaround is to either disable debug or add the following line in
$G4SOURCE/CMakeLists.txt
:
set(CMAKE_CXX_FLAGS "-fno-threadsafe-statics")
There is also a patch in http://leaf.dragonflybsd.org/~beket/CMakeLists.txt.diff that applies the above change. Since we are interested in the sequential code path efficiency, we chose to disable thread safe statics instead of debugging symbols. Question: what about the impact on performance due to lack of optimizations ?
When building granular libraries, one needs to set $PATH like:
export PATH=/usr/gnu/bin:$PATH
so that the GNU toolchain takes precedence over the native, otherwise some commands will fail (e.g., @$(GREP), etc).
Use Linux-g++ as G4System
The GNUmakefile
couldn’t generate the libname.map
file. It would flood
with errors from grep(1)
, of the form:
grep: error: missing argument for operation -- e
The modified file that works ok is this:
the http://leaf.dragonflybsd.org/~beket/geant4/GNUmakefile2 . Soon,
I’ll have a unified diff against the original and integrate it with
setup.sh
.
After the granular libraries have been built by running gmake in
$G4INSTALL/source
, trying to build FullCMS
results to this:
stathis:calorimeter/FullCMS% sudo -E gmake
Using granular libraries ...
Linking full_cms
Undefined first referenced
symbol in file
G4GeometryTolerance::GetSurfaceTolerance() const
/home/stathis/gen-tests/geant4/geant4.9.5.p01/tmp/Linux-g++/full_cms/libfull_cms.a(MyDetectorConstruction.o)
G4UIcmdWithADoubleAndUnit::SetDefaultValue(double)
/home/stathis/gen-tests/geant4/geant4.9.5.p01/tmp/Linux-g++/full_cms/libfull_cms.a(MyDetectorMessenger.o)
CLHEP::HepRandom::setTheSeed(long, int)
/home/stathis/gen-tests/geant4/geant4.9.5.p01/tmp/Linux-g++/full_cms/exe/full_cms.o
... lots of similar errors ...
stathis:calorimeter/FullCMS% nm $G4LIB/$G4SYSTEM/libG4globman.a \
| grep GetSurface | /usr/gnu/bin/c++filt
000000e0 T G4GeometryTolerance::GetSurfaceTolerance() const
ld: fatal: library -lG4heprandom: not found
ld: warning: file ../../../../../../outputs/library/SunOS-g++/libG4procman.so: attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/libG4volumes.so: attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/libG4track.so: attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/libG4partman.so: attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/libG4geometrymng.so: attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/libG4materials.so: attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/libG4intercoms.so: attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/libG4globman.so: attempted multiple inclusion of file
ld: fatal: file processing errors. No output written to ../../../../../../outputs/library/SunOS-g++/libG4emdna-molman.so
collect2: ld returned 1 exit status
make[2]: *** [outputs/library/SunOS-g++/libG4emdna-molman.so] Error 1
make[2]: Leaving directory `/home/stathis/gen-tests/geant4/geant4.9.5.p01-build-smart'
make[1]: *** [source/processes/electromagnetic/dna/molecules/management/CMakeFiles/G4emdna-molman.dir/all] Error 2
make[1]: Leaving directory `/home/stathis/gen-tests/geant4/geant4.9.5.p01-build-smart'
make: *** [all] Error 2
1.3. How to find memory leaks with libumem
First, set some environmental variables in order to use the libumem
memory allocator:
LD_PRELOAD=libumem.so.1; export LD_PRELOAD
UMEM_DEBUG=default; export UMEM_DEBUG
Then use mdb
to run your binary:
/usr/bin/mdb /home/stathis/gen-tests/geant4/geant4.9.5.p01/bin/Linux-g++/full_cms
:r ./bench1_10.g4
....
^C
mdb: stop on SIGINT
mdb: target stopped at:
_ZN10G4QPDGCode9MakeQCodeERKi+0x43e: leal (%eax,%eax,2),%ebx
mdb: You've got symbols!
Loading modules: [ ld.so.1 libumem.so.1 libc.so.1 libuutil.so.1 libnvpair.so.1 ]
Then use ::findleaks
dcmd to -guess what- find the memory leaks:
> ::findleaks -dv
findleaks: using cached results (use '-f' to force a full run)
CACHE LEAKED BUFCTL CALLER
099bf390 1 0aa867c8 libstdc++.so.6.0.14`_Znwj+0x29
099bf390 1 0ac60438 libstdc++.so.6.0.14`_Znwj+0x29
099bf390 1 0ac60780 libstdc++.so.6.0.14`_Znwj+0x29
...
Enable C++ symbol demangling and walk through all the leaked buffers, acquiring
the stack trace that led to that leak and output everything to the umem.txt
file:
> $G
C++ symbol demangling enabled
> ::walk leak | ::bufctl_audit !tee umem.txt