Problem 1075

I have been trying for a week to get shared libraries to work, even though it works out-of-the-box for other people. I have traced the problem to an invalid dependency on the order of static initializers. For some unknown reason I get a different load order than other people, and this has slipped through your testing.

The specific instance I found is in processes/hadronic/models/rpg/src/G4RPGInelastic.cc, near the end where there are 18 initializers of the form:
  G4ParticleDefinition* p0 = G4PionZero::PionZero();
  ... 17 more

The problem comes when G4RPGInelastic.o is linked before the standard energy-loss processes, probably G4LossTableManager.cc. When the G4RPGInelastic initializers come first, they result in some energy-loss process without a G4ProcessManager getting Register()-ed with the G4LossTableManager. The resulting NULL pointer causes a crash inside G4ProcessManager::GetProcessActivation() called by G4LossTableManager::EnergyLossProcessIsInitialised(). Yes, this is subtle.

That happens for me whenever I build shared libraries, and also when I link exampleN01 manually after modifying it to use QGSP_BIC rather than its own physics list. I tracked it down with the latter method, varying the order of linking until I narrowed the problem down to this file. I replaced those 18 particle initializers with 0 and re-built -- now the link order does not matter and the shared libraries now work. QGSP_BIC does not use this RPG model, so my test-only change is OK.

Note my search was NOT exhaustive, and it is possible (even likely) that other classes have a similar disease. It's just that they happened to not crash for me (nor for your testing). An exhaustive search is non-trivial.

This can be fixed in several ways, either moving those static initializers into the class constructor, or better by making the whole energy-loss registration scheme become independent of initializer order. I don't know the code well enough to evaluate either of these approaches; nor do I know how many other classes have similar dependencies on initializer ordering. 

This is on Mac OS X 10.5.7 in a fresh login with no historical environment changes, using Xcode 3.1.3, CLHEP 2.0.4.2, and Geant4.9.2.p01. This order dependency is independent of OS, and it appears to me that your testers were unlucky and never had a load order that triggered the crash.