Error messages when calling TThread::Initilialize

ROOT
1

Hello,

Migrating from ROOT 6.26.08 (centos9) to ROOT 6.28.04 (el9) the error output (stderr) of my application is now filled with many error messages triggered by the call to TThread::Initialize.

The error messages start as follows:

<<< cling interactive line includer >>>: fatal error: module file '/build/jenkins/workspace/lcg_release_pipeline/build/projects/ROOT-6.28.04/src/ROOT-6.28.04-build/lib/Vc.pcm' not found: module file not found
<<< cling interactive line includer >>>: note: imported by module 'MathCore' in '/cvmfs/sft.cern.ch/lcg/releases/ROOT/6.28.04-740f6/x86_64-el9-gcc11-opt/lib/MathCore.pcm'
input_line_4:2:2: error: unknown type name 'include'
#include "TError.h"
 ^

In my environment I can reproduce the problem with:

int main() {
  TThread::Initialize();
  return 0;
}

I wish I can attach the complete log file for reference but "new users cannot add links to posts)

Any idea how to investigate/fix this?

Cheers,
Fabrice

2

Dear Fabrice,

Thanks for posting this question. The ROOT release you are using is part of the LCG releases the SFT group at CERN delivers to the community via CVMFS, i.e. a set of several packages for HEP, compiled coherently. My proposal would be to use the LCG release instead of the single ROOT build as I understand you are doing. Could you try:

source  /cvmfs/sft.cern.ch/lcg/views/LCG_104/x86_64-el9-gcc11-opt/setup.sh

It works for me on a EL9 node.

Cheers,
D

3

Hello Danilo,

Thank you for the input.

Indeed the environment in which I’m running the application (ATLAS TDAQ) has a good fraction of the LCG environment imported.

I further investigated the issue trying to understand the difference between the two environments (6.26 vs 6.28) and could not find any but I did find a way to fix the problem. If I set the following variable in the environment of the application, error messages do not show up:

export ROOT_INCLUDE_PATH=/cvmfs/sft.cern.ch/lcg/releases/LCG_104/Vc/1.4.3p1/x86_64-el9-gcc11-opt/include

This is not necessary in the 6.26 environment. Are you aware of any change that would explain this?

Also I would like to understand how the environment should be properly set. Are we expected to set this variable and where exactly should it point to?

4

Hi Fabrice,

There was no significant change in this respect. I think the point here is that the LCG releases come as a coherent set of packages, with all the proper environment set. I understand you are trying to strip it down a bit, correct me if I am wrong, and that could be the cause of the issue. The environment of the LCG releases is set by sourcing the setup.(c)sh script in the /cvmfs/sft.cern.ch/lcg/releases/LCG_XYZ directories.

I hope this helps.

Cheers,
Danilo

5

I can indeed not reproduce the problem with in an LCG env. I managed to convince myself that the problem is located in our specific environment. I’ll investigate further on this side.

Thanks again

6

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