Package Details: geant4 11.0.0-1

Git Clone URL: (read-only, click to copy)
Package Base: geant4
Description: A simulation toolkit for particle physics interactions.
Upstream URL:
Licenses: custom:
Conflicts: geant4_devel
Submitter: Eothred
Maintainer: donpicoro
Last Packager: donpicoro
Votes: 15
Popularity: 0.004735
First Submitted: 2010-04-08 08:54
Last Updated: 2021-12-15 14:12

Dependencies (23)

Sources (2)

Latest Comments

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

gipert commented on 2022-01-25 16:44

Forget about my last comment. I tested the new driver a bit and found it quite unstable, at least on Arch. We should maybe reconsider it once the feature is more mature.

gipert commented on 2022-01-13 15:57

Hello @donpicoro, thanks a lot for keeping the package up to date. What about supporting the VTK visualization driver?

donpicoro commented on 2021-07-13 14:57

Hello once more @gipert:

it turned out much easier than I thought. I do not want to bump the release to avoid unnecessary re-compilations. However I already tested in my machine and it works for me and they should be there when the next release or patch comes out.

1) The std17: It juts works, so I just changed it to GEANT4_BUILD_CXXSTD=17

2) ldconfig : it turns out that the geant.[c]sh was mainly setting some Xerces, etc... libraries which they all live, along with the new G4 ones, under /usr/lib. It turns out that /usr/lib is actually included by default by ldconfig. So... there is nothing to add there even ;-)

gipert commented on 2021-07-13 13:24

Hi @donpicoro. Indeed the right way is to add a config file below /etc/

As for the standard, I'm only suggesting this because it's a general practice in Arch Linux packages to compile the C++ sources with recent standards (see e.g. ROOT). Not a big issue just a remark.

donpicoro commented on 2021-07-09 17:20

Hello again @gipert:

I see your point with the LD_LIBRARY_PATH. For now I will not modify things as you seem to be the only one being affected by this. I will however investigate the possibility to add this in /etc/*.conf as it seems to be place to put it according to /etc/ and my simple understanding of this. I have never done this so let's see whether I manage for the next release in December.

As for the compilation standard... I meant that the minimum supported for the next version will be c++17 if I'm not mistaken. I misunderstood your remark. I myself have not fiddled with non-default standards but I'll give them a whirl for the next release as well.


gipert commented on 2021-07-09 16:56

Hi @donpicoro, thanks for the notes, I forgot Geant4 data is installed through separate packages. By the way, I know that you're just installing as it is. The problem is that setting LD_LIBRARY_PATH globally is bad practice and can break other software (see e.g. here). This happened to me lately (see here), and I had to remove to fix the issue.

Of course this should be somehow fixed/clarified in Geant4, and what I'm suggesting here is at least to just avoid sourcing by default, if the software is installed below /usr/local and is anyhow globally visible. You could add a warning printout during package installation and let the user decide what to do with it.

Le me know what you think and thanks for maintaining the package!

PS: on the C++ standard, I assume the official docs are wrong then?

donpicoro commented on 2021-06-30 21:28

Hello @gipert:

  • compiling with C++17 standard: Geant4 does not yet support that standard. This will come in version 11 in early december. Stay tuned.

  • LD_LIBRARY_PATH in /urs/bin/ I just source it because those as the instruction. The script is left 100% vanilla. NOTE that this script does not set the DATA environment variables. That I handle in separate scripts as they are optional dependencies... this was the easiest and most sustainable way to deal with this.

gipert commented on 2021-06-29 14:00

Sourcing /urs/bin/ by default is a good idea, to get the Geant4 data env variables automatically set. That script is nasty though, because it sets LD_LIBRARY_PATH, which is both useless and possibly breaks other software. What about stripping that line from the script?

gipert commented on 2021-06-29 13:54

What about compiling with the C++17 standard?

hugo_loio commented on 2021-04-11 17:09

Thank you very much for the help @donpicoro!