Package Details: geant4 11.2.1-1

Git Clone URL: (read-only, click to copy)
Package Base: geant4
Description: A simulation toolkit for particle physics interactions.
Upstream URL:
Keywords: matter montecarlo radiation transport
Licenses: custom:
Conflicts: geant4_devel
Submitter: Eothred
Maintainer: donpicoro
Last Packager: donpicoro
Votes: 19
Popularity: 0.013839
First Submitted: 2010-04-08 08:54 (UTC)
Last Updated: 2024-02-17 01:36 (UTC)

Dependencies (24)

Sources (2)

Latest Comments

1 2 3 4 5 6 .. 15 Next › Last »

Ifnister commented on 2024-03-12 09:13 (UTC)

Hi @donpicoro,

sounds good, many thanks! I'll try the new version once it's out.


donpicoro commented on 2024-03-11 10:54 (UTC)

Hello @ifnister,

as I said before, I myself have no strong argument to keep it as is. You provide a good argument to use the external CLHEP and since no one has weighted in in either direction I will change it.

I will do it in connection with the next patch release as I do not want to trigger an unnecessary compilation for everyone.


Ifnister commented on 2024-03-09 09:39 (UTC)

Hi @donpicoro,

coming back to the CLHEP issue that I mentioned before, and after some thought and having worked with this Geant4 package I now think that depending on an external CLHEP should be the default because: - By default Geant4 brings its own version of CLHEP so not much is saved by not depending on CLHEP other than whatever stripping is done by Geant4 on their own version of CLHEP - When building something on top of Geant4 and linking to it, the flag -lG4clhep will be added together with a path to the CLHEP library provided by Geant4. If you have something that happens to depend on CLHEP and Geant4 at the same time, well then there will be issues since the CLHEP libraries are not the same. One possible workaround would be to make sure only the CLHEP installation from G4 is used, but we have a better way of having a standard installation that every package can use - use the clhep package instead of the library provided by Geant4

This is how, for example, the LCG stacks (the stacks of software used by some LHC experiments) install Geant4 since you don't want to have two different installations of CLHEP around.


donpicoro commented on 2024-01-22 16:51 (UTC)


I had to patch the G4InterfaceOptions.cmake to accept 1.6.1 and I realized that SoQt bring a dependency to Qt6, so now it build on qt6. I tested on my system and the application worked. I no longer could use /vis/open OGLSQt but if I swapped it for /vis/open OGL or /vis/open DAWNFILE it does work.

I hope this works for people.


donpicoro commented on 2024-01-22 14:41 (UTC) (edited on 2024-01-22 15:15 (UTC) by donpicoro)

OK, I'm looking into it... this didn't happened when I updated the package. This is more recent. The bright side is that I can reproduce the error ;-)

It is Geant4 that demands SoQt 1.6.0... I'll see if I can find a workaround.

Eothred commented on 2024-01-16 12:26 (UTC) (edited on 2024-01-16 12:30 (UTC) by Eothred)

I'm getting some error with SoQt version when trying to build version 11.2.0-1. Seems very specific to demand exactly version 1.6.0?

Edit: for now just disabled the inventor_qt option to avoid the dependency on soqt.

CMake Error at cmake/Modules/G4InterfaceOptions.cmake:142 (find_package):
  Could not find a configuration file for package "SoQt" that is compatible
  with requested version "1.6.0".

  The following configuration files were considered but not accepted:

    /usr/lib/cmake/SoQt-1.6.1/soqt-config.cmake, version: 1.6.1
    /lib/cmake/SoQt-1.6.1/soqt-config.cmake, version: 1.6.1

donpicoro commented on 2023-09-18 09:38 (UTC)

Hello @ifnister

There is no real strong argument for one or the other. I maintain both packages because I use to build Geant4 as a full dependency, so it was convenient.

The only reason to drop it as an explicit dependency is that Geant4 does not really include CLHEP. From the documentation ( it is explicitly mentioned that it is a minimal version of clhep.

If I were to have the "full" CLHEP as a dependency, I may get a user saying that this way would be better.

In reality both are fine and I do not mind either way... but you know... a decision has to be made and people has opinions on decisions. If more users come forward with the same request I do not mind change it at all.

For the time being, while people express opinions, if any, an since this is such a small adjustment in the PKGBUILD, I suppose you can do it yourself?

This package is updated about 3 times a year. - new release in first week of december - couple of patches version during the year



Ifnister commented on 2023-09-15 12:14 (UTC)

Would it be interesting to build it with CLHEP? Most of the time it has to be installed for other packages (in which case it is worse to have also the CLHEP from AUR as you have two installations in your system) and it would only add one dependency; and the maintainer is the same person. For me it would be nice to have it

Eothred commented on 2022-11-07 15:32 (UTC)

That's not to be defined in the PKGBUILD, so the maintainer is correct in doing it this way. makepkg can be configured for parallel builds, see

Firestar commented on 2022-11-07 15:20 (UTC)

I found that you enabled GEANT4_BUILD_MULTITHREADED=ON but make do not have the -j parameter. Can you enable it as the compilation is very slow?