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?).


export ICUROOT="/usr"           # assuming libicu is in /usr/lib/
cd xerces-c-3.1.1 && ./configure --prefix=/opt/xerces-c-3.1.1 \
                  && gmake && gmake install
Note 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   \

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.

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

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:


or modify the CMAKE_CXX_FLAGS variable, again inside the CMakeLists.txt.

1.2.2. FullCMS

  1. fast notes …

export XERCESROOT=/opt/xerces-c...

setup the environmental variables …

apply the patch 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

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 |\
     /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 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 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 . Soon, I’ll have a unified diff against the original and integrate it with

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


CLHEP::HepRandom::setTheSeed(long, int)
... 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++/ attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/ attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/ attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/ attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/ attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/ attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/ attempted multiple inclusion of file
ld: warning: file ../../../../../../outputs/library/SunOS-g++/ attempted multiple inclusion of file
ld: fatal: file processing errors. No output written to ../../../../../../outputs/library/SunOS-g++/
collect2: ld returned 1 exit status
make[2]: *** [outputs/library/SunOS-g++/] 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:; 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
mdb: stop on SIGINT
mdb: target stopped at:
_ZN10G4QPDGCode9MakeQCodeERKi+0x43e:    leal   (%eax,%eax,2),%ebx
mdb: You've got symbols!
Loading modules: [ ]

Then use ::findleaks dcmd to -guess what- find the memory leaks:

> ::findleaks -dv
findleaks: using cached results (use '-f' to force a full run)
099bf390       1 0aa867c8`_Znwj+0x29
099bf390       1 0ac60438`_Znwj+0x29
099bf390       1 0ac60780`_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