Home | News | Documentation | Download

Garfield++ / Root Errors - fatal error: TCanvas.h: No such file or directory

Hello,

So I’m trying to run a simulation in Garfield++ and as far as I can tell I almost have it working. Root, Geant4, Garfield, and SRIM/TRIM are all installed and I think they all work individually but I get the following error when I try to run something of my own with make.

/home/jason/garfieldpp/Examples/IsobutaneGrid/grid.C:8:10: fatal error: TCanvas.h: No such file or directory
    8 | #include <TCanvas.h>
      |          ^~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/grid.dir/build.make:82: CMakeFiles/grid.dir/grid.C.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:95: CMakeFiles/grid.dir/all] Error 2
make: *** [Makefile:103: all] Error 2

I think this is saying that Garfield and Root aren’t communicating with each other properly, but I’m not 100% sure of that. I do know that if I try to open it up in ccmake I see this.

 CMAKE_BUILD_TYPE
 CMAKE_INSTALL_PREFIX             /usr/local
 Garfield_DIR                     /home/jason/garfieldpp/CMake
 ROOT_DIR                         /snap/root-framework/202/usr/local/cmake     
 ROOT_genmap_CMD                  ROOT_genmap_CMD-NOTFOUND
 ROOT_rootdraw_CMD                ROOT_rootdraw_CMD-NOTFOUND

I suspect that if I can fix those last two lines it’ll solve my problem but I’m not really sure how to do that.

Any help would be appreciated.


Please read tips for efficient and successful posting and posting code

ROOT Version: 6.24/00
Platform: Ubuntu 21.04
Compiler: g++ 10.3 / cmake 3.18.4 when appropriate


The path used by the snap itself for ROOT’s own includes is /snap/root-framework/current/usr/local/include, but I suspect simply adding this include folder might not be the only problem.

Unfortunately the snap package of ROOT isn’t designed to integrate with other packages in this manner, as a combination of technical problems of being a container based package and bad user experience that can be dealt with better by using alternate options. Having looked inside the cmake folder the snap provides, the metadata is erronous and likely unusable which would explain why it isn’t setting up the INCLUDE paths properly.

Since Ubuntu 21.04 doesn’t have a precompiled version available yet, you could try the Conda package as an alternative which might work for you. Alternatively you could consider compiling your own version of ROOT, which would guarantee consistency with your host system.

I’ll schedule some time to look into Garfield++ and fixing up the cmake metadata in the ROOT snap, however there’s a large chance that it might be impossible to make a good experience due to the interaction between differing compiler versions, std libraries, etc. For the time being, using another package is likely your best option.

Those are all very good ideas. Can’t promise I’ll try them all tonight but I’ll try them in the next day or two.

I am a little bummed that two out of three of your proposed solutions involve uninstalling and reinstalling at least ROOT - but I was starting to suspect something like that.

Alright, update. I uninstalled and reinstalled Root 6.22 by compiling it myself.

#--- Dependencies -------------------------------------------------------------
if(DEFINED ENV{ROOTSYS})
  list(APPEND CMAKE_PREFIX_PATH $ENV{ROOTSYS})
elseif(DEFINED ROOTSYS)
  list(APPEND CMAKE_PREFIX_PATH ${ROOTSYS})
elseif(DEFINED ROOT_CMAKE_DIR)
  list(APPEND CMAKE_PREFIX_PATH ${ROOT_CMAKE_DIR})
# else()
#   message(
#     STATUS
#       "Please consider to set ROOTSYS or use -DROOTSYS=..."
#       "If still there is a problem, point to the directory which includes FindROOT.cmake using -DROOT_CMAKE_DIR=..."
# )
endif(DEFINED ENV{ROOTSYS})

Not entirely sure what you’re going for. I can confirm that the CMakeLists file already has this code in it.

I’m showing you which environment variable is checked: ROOTSYS. You don’t have it set.

Setting it to "${ROOT_DIR}" or "${ROOT_DIR}/../../.." should/might help.

Ah. I got a work-around in place using ccmake alright but now that I see what you were going for, yeah - I think that would have worked. Thank you.

Edit:- I do think I have garfield++ working now, but I’m not done testing it to know for sure. I’ll keep you all up to date when I’m sure.

I think it possibly would have worked, but it’s an unclean solution because there will almost certainly be subtle bugs and ABI incompatibilities.

I tried building garfield with the snap today on a clean system, I couldn’t even get to same point because CMake was generating make files that called the ROOT binaries directly rather than with their wrappers. Presumably, the reason you were able to do it is because by sheer chance (likely as a result of setting up Geant/Garfield/etc) you happened to have copies of every single library that ROOT also happens to use in your normal paths. These libraries might happen to work, but they also are likely to break at any random point if either the snap or your system has an update, or crash at random as you actually try to work with them.

There’s an option I can investigate for the ROOT snap known as classic mode in the snap ecosystem. In theory, it could provide a path for a ROOT build that would be able to run in the host system rather than in a container, being able to use any arbitrary binaries and see any arbitrary files, effectively transitioning from a quasi docker-like package to a quasi conda-like package, and thus potentially being able to integrate with Geant/Garfield/etc. Unfortunately it’d take a long time to consider how feasible it is and might not be a fruitful endevour.

Hopefully your attempts to get Garfield running with the self compiled version are successful, and thanks for the feedback on the snap too :).

The new build doesn’t use the snap framework, and I noticed that while it still has the genmap and rootdraw not found issue it seems to work. [Again, not entirely sure about that because I’m not done testing it. I just know that as of now is that it seems to have installed with no issues and seems to be working.]

2 Likes

Ah. Yeah, that would definitely explain why ROOT and Garfield++ seem to work just fine without them. Because they’re vestigial code artifacts anyway. Thank you for that.

Update - Flagged the solution that ultimately worked because that was the basic strategy. Took a bit of finesse with ccmake but it is all working now.

Update - Might have been a touch pre-mature. Examples seem to work but something I write myself doesn’t, with the same error. Still trying to figure it out.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.