Compilation failing because ROOT is searching for files in the source directory, and not in the installation directory

ROOT
1

Dear all,

We have recently installed ROOT v6.22.06 and v6.23.01. The basic tests are ok, and ROOT (both versions) seems to run smoothly.

However, a colleague of mine recently had some issues to access data through XRootD (data are stored in XCache, and read through XRootD). The main bash script launches ROOT and compiles a macro to access the data through XRootD and use TChain to chain them before analysis.

The problem is at the compilation time. For some reason, some include files and libraries are searched in the source / compilation directory and NOT in the final installation directory. All libraries are in the installation directory, so I do not understant why ROOT is searching them in the compilation directory, and the headers it is looking for are in the system (/usr/include).

Please see below a piece of the failing compilation, with some examples showing the issue.

cc1plus: fatal error: /pbs/throng/ccin2p3/support/gadrat/software/centos-7-x86_64/root/build_v6-22-06/include/stdc-predef.h: Permission denied
compilation terminated.

Here, the stdc-predef.h file should be found in the /usr/include directory, not in the compilation directory

Right after that we have:

c++: error: /pbs/home/g/grahal/ESCAPE-tests/exercise_analysis_atlas/atlas-outreach-cpp-framework-13tev/Analysis/HyyAnalysis/HyyAnalysis_C_ACLiC_dict.o: No such file or directory
Error in <ACLiC>: Executing 'cd "/pbs/home/g/grahal/ESCAPE-tests/exercise_analysis_atlas/atlas-outreach-cpp-framework-13tev/Analysis/HyyAnalysis" ; c++ -O3 -DNDEBUG "/pbs/home/g/grahal/ESCAPE-tests/exercise_analysis_atlas/atlas-outreach-cpp-framework-13tev/Analysis/HyyAnalysis/HyyAnalysis_C_ACLiC_dict.o" -shared   "/usr/lib64/libdl.so" "/usr/lib64/libc.so" "/usr/lib64/libm.so" "/pbs/software/centos-7-x86_64/root/6.22.06/lib/libRint.so.6.22" "/pbs/software/centos-7-x86_64/root/6.22.06/lib/libCore.so.6.22"
[...] Now dealing with XRootD libraries
 "/pbs/software/centos-7-x86_64/root/6.22.06/lib/libNetxNG.so.6.22.06" "/pbs/software/centos-7-x86_64/root/6.22.06/lib/libXrdUtils.so.2" "/pbs/software/centos-7-x86_64/root/6.22.06/lib/libXrdClient.so.2" "/pbs/software/centos-7-x86_64/root/6.22.06/lib/libXrdCl.so.2"

But now ROOT is searching for them back in the compilation directory, though they are in the installation directory !

"/pbs/throng/ccin2p3/support/gadrat/software/centos-7-x86_64/root/build_v6-22-06/lib64/libXrdXml.so.2" "/pbs/software/centos-7-x86_64/root/6.22.06/lib/libsetDict.so.6.22.06" "/pbs/throng/ccin2p3/support/gadrat/software/centos-7-x86_64/root/build_v6-22-06/lib64/libXrdSec-4.so" "/pbs/throng/ccin2p3/support/gadrat/software/centos-7-x86_64/root/build_v6-22-06/lib64/libXrdSecgsi-4.so" "/pbs/throng/ccin2p3/support/gadrat/software/centos-7-x86_64/root/build_v6-22-06/lib64/libXrdCrypto.so.1" -o "/pbs/home/g/grahal/ESCAPE-tests/exercise_analysis_atlas/atlas-outreach-cpp-framework-13tev/Analysis/HyyAnalysis/./HyyAnalysis_C.so"' failed!

Finally the compilation is failing, because a header file, and some XRootD libraries are not found.

Does anyone know what’s going on here?
Why ROOT is not searching for header and libraries in the correct PATHs?

Of course, for people who have access to the compilation directory, everything works as a charm!

Thanks for your help,
Regards,

SĂ©bastien

Please read tips for efficient and successful posting and posting code

ROOT Version: 6.22.06 & 6.23.01
Platform: linuxx8664gcc
Compiler: gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3) (devtoolset-8)

2

Salut Sebastien,

Thanks for reporting. This is indeed strange. Where does stdc-predef.h come from? How did you configure ROOT, can you share its CMakeCache.txt?

Cheers, Axel.

3

Hello Axel,

And thanks for your help!

I don’t really know where does the check of stdc-predef.h comes from. When my colleague runs her code, it requires it if the compilation directory is not found (which is the case by default, since I compiled it in a kind of private area). I found nothing obvious from the code itself, then I tried to run it with strace, but it did not help since the “master” code then compiles some specific codes, and then strace did not trace this new compilations anymore (or maybe I have to be clever when using the options of strace).

I have joined the CMakeCache.txt.

Cheers,

SĂ©bastien

4

With the attached CMakeCache.txt file it is better!

Thanks!

CMakeCache.txt (141.2 KB)

5

Hello Axel, all,

Well, I guess we are all ‘offline’, enjoying some vacations


But do you have any idea about my problem?

Happy end of year vacations!

Cheers,

SĂ©bastien

6

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

7

Sorry, Sebastien, just overloaded, thanks for pinging me!

Can I see the compiler invocation that causes

cc1plus: fatal error: /pbs/throng/ccin2p3/support/gadrat/software/centos-7-x86_64/root/build_v6-22-06/include/stdc-predef.h: Permission denied
compilation terminated.

e.g. by means of make VERBOSE=1?

9

Hello Axel,

Sorry for the delay, I don’t have access to the code itself, so I need to discuss the issue with the user who sees it.

The code is part of a bigger framework, and the user is trying to reproduce the bug from a smaller piece of code, which could be shared with us.

Up to now, here is how things works. The main code is compiled by ROOT with a
root > .L main_analysis.C+

This will produce a main_analysis.so which, once loaded, and when run the main() it will again compile some sub-analysis programs. The error above comes from when ROOT compiles one of the sub-program.

So how can I get the verbose version of that compilation?

From the ROOT prompt, if I check the config, i.e. root-config, everything looks OK.

I hope we can manage to get a small set of codes that we could share.

Thanks for your help,
Cheers,

SĂ©bastien

10

Please ask your user to run

ROOTDEBUG=7 root main_analysis.C+

This will create a ton of output; it would be great if you could share that output. Ideally by automatizing the error such that no interactivity is needed:

ROOTDEBUG=7 root -q -e 'main_analysis.C+' -e 'main_analysis()` > out.txt 2>&1

or similar.

11

Hello Axel,

Thanks for your quick answer!

Our user managed to create a small set of pieces of code which allows to reproduce the error.

The following command can trigger the error:
$ ROOTDEBUG=7 root -b SignalModel.C+ > out.txt 2>&1

However, a small progress is that it seems this is environment related, as I cannot reproduce the error when running the code on my side.

Please find attached two output files.

  • out_good.txt is what I get when running the following command in the code directory in my own environment
  • out_bad.txt, which is what our user gets when running in his own environment.

PS: not sure mine is “good”, but at least I can run the code without getting any error.

I can provide the set of codes if needed.

The main code, i.e. “SignalModel.C” compiles at some point a second macro “RooTwoSidedCBShape.cxx”, this is when the error appears (line 5202), i.e. something like

cc1plus: error: /pbs/throng/ccin2p3/support/gadrat/software/centos-7-x86_64/root/build_v6-22-06/include: Permission denied
cc1plus: error: /pbs/throng/ccin2p3/support/gadrat/software/centos-7-x86_64/root/build_v6-22-06/include/: Permission denied

However, there is another error which pops up earlier (first at line 737, and twice more later):

/pbs/software/centos-7-x86_64/root/6.22.06/include/root/TDirectoryFile.h:31:1: error: incomplete type ‘TKey’ named in nested name specifier

Thanks,
Cheers,

SĂ©bastien

Some more information:

  • ROOT v6.22.06
  • compiled against Python 3.8.6
  • and with GCC 8 (from the RH devtoolset-8)
  • the correct ROOT installation PATH is /pbs/software/centos-7-x86_64/root/6.22.06/

out_good.txt (320.9 KB) out_bad.txt (591.7 KB)

12

Hi, I am also affected by a very similar bug with v6.22.06. I grepped for the source paths in the installation directory and I found that they appear in the following files:

bin/root-config  # in the srcdir variable, unsurprisingly
config/Makefile.config  # in ROOT_SRCDIR and ROOT_OBJDIR

These occurrences do not seem related to the problem at hand. On the other hand, the source paths occur many many times in the binaries (libraries). I am not sure exactly what happens, but the problematic paths end up in a -I argument to g++ when I call gROOT->LoadMacro("somescript.C+").

I can provide more information if necessary.

Kind regards,
Davide

13

Some additional information: the missing source/build paths show up already in the output of gInterpreter->GetIncludePath().

14

May be another instance of Instantiating a ROOT.vector adds the build directory to cling's include paths · Issue #7108 · root-project/root · GitHub ?

15

@eguiraud this looks promising! Do you know which is the most recent unaffected version?

16

The issue is still open (work in progress :smiley:) but the last comment suggests a workaround/solution.

2 Likes
17

Thanks @eguiraud
I will try this out and let you know.
Cheers.

18

Thanks @eguiraud ! I tried out the fix given in the GitHub link above, and it fixed my problem!

I will now manually patched the ROOT sources, until the fix is ported directly into them.

Closing my issue.

Cheers,

SĂ©bastien

19

Thank you for letting us know!

20

The fix works for me, too!