O2 build fails in CentOS 7 due to GLFW

Hi Andry,

As far as I can tell, the generation is failing because one of the macro references a target (O2::SimSetup) that is only available when BUILD_SIMULATION is ON.

Could you run the following in your build directory and post the result ?

grep BUILD_SIMULATION CMakeCache.txt

According to your log you request to not build the simulation but then Geant4 is actually found and it seems the guard used for that macro is inconsistent with this (unforeseen) situation (which is something we might need to fix eventually)

But then in principle --defaults o2 is asking BUILD_SIMULATION=ON so I’d like to understand where the BUILD_SIMULATION=OFF is coming from in your setup

Cheers,

Hi Laurent,

Thanks for your hint.

Here is the result of the grep command:

BUILD_SIMULATION:BOOL=OFF
//Default behavior for simulation (disregarded if BUILD_SIMULATION
BUILD_SIMULATION_DEFAULT:BOOL=ON

Best regards,
Andry

ok, thanks. While I don’t understand why the BUILD_SIMULATION is OFF, it shows there’s a logic problem in the macro/CMakeLists.txt that I’ll have to fix.

Meanwhile, to get you going, could you either :

  • edit the CMakeCache.txt to make the BUILD_SIMULATION=ON
    (which should give you a working build with simulation parts included, as we usually get when doing aliBuild --default o2 build O2)

  • change line 190 of macro/CMakeLists.txt to :
    if(Geant4_FOUND AND BUILD_SIMULATION)
    (which should give you a working build but without simulation parts)

Dear Laurent,

Your trick did it: the build is successful. Thanks a lot!

Cheers,
Andry

for the record the fix is now in AliceO2 https://github.com/AliceO2Group/AliceO2/pull/4437

1 Like

Very prompt action! Thanks a lot!

Hi @laphecet,

I am trying to enable back the build of the simulation (as we need it to get the map of the detector to extract the sensor hardware id from their software id written in the digits from the decoded raw data files).

So I have been investigating why BUILD_SIMULATION was OFF. It is because HepMC3 package was not detected during the O2 cmake process: in the sw/BUILD/O2-latest/O2/CMakeCache.txt, one could read the following lines

//The directory containing a CMake configuration file for HepMC. HepMC_DIR:PATH=HepMC_DIR-NOTFOUND

which is strange because HepMC3 was built earlier by aliBuild and the directory exists. In particular the cmake config files for HepMC3 are located at:

/home/alice/alice/sw/slc7_x86-64/HepMC3/3.2.2-1/share/HepMC3/cmake

I replaced HepMC_DIR-NOTFOUND with this path in CMakeCache.txt and executed a make from sw/BUILD/O2-latest/O2/ directory. Unfortunately, some cmake process keeps overwriting the path and put back HepMC_DIR-NOTFOUND. So this workaround does not work. The best would be to improve the find logic of HepMC3 in the .cmake files, but I could not figure out what to change.

Maybe you may have some ideas on this?

Thanks in advance,

Cheers,
Andry

Hi Andry,

I’m confused : for the simulation part HepMC3 (i.e. HepMC version 3) is required, not HepMC (see dependencies/O2SimulationDependencies.cmake) ?

Anyway to debug cmake package issues, one can try to use cmake . --debug-find in the build dir (this will spit out verbose stuff from the find_package calls)

Hi @laphecet,

Thanks for your answer.

It was the crucial hint: our custom branch did not have the latest dependencies/O2SimulationDependencies.cmake nor dependencies/FindHepMC3.cmake that are using indeed HepMC3.

It is now solved and the simulation is also successfully built.

Thanks again,

Cheers,
Andry