root6: headers broken

[lpgaff (Liam Gaffney)]

I am compiling my own code against the ROOT libraries and when it comes to building the dictionaries it fails with the error:

In file included from TreeBuilderDictionary.cc:12:
/opt/local/libexec/root6/include/root/RConfig.h:22:10: fatal error: '../RVersion.h' file not found
#include "../RVersion.h"
         ^~~~~~~~~~~~~~~
1 error generated.
make[1]: *** [TreeBuilderDictionary.o] Error 1
make: *** [TreeBuilder] Error 2

The file at /opt/local/libexec/root6/include/root/RConfig.h is actually a link to the real file at /opt/local/libexec/root6/include/root/ROOT/RConfig.h. Hence, the include you see for RVersion.h goes up one directory. However, clang seems to take the location of the linked file, not the real file, so RConfig.h cannot be found.

I can "fix" this by changing #include "../RVersion.h" to #include "RVersion.h" in the file /opt/local/libexec/root6/include/root/ROOT/RConfig.h, but this seems to be unsatisfactory.

Can anybody find a better fix, or explain the reason that the compiler doesn't resolve the static link to RConfig.h, or infact why a static link is required at all?

Cheers, Liam

[cjones051073 (Chris Jones)]

Looks like a duplicate of the issue in

#57007

can you please try the work arounds discussed there ?

[lpgaff (Liam Gaffney)]

I looked at the previous ticket (#57007) and can conclude that it is basically the same bug. However, the symlinks in the /opt/local/include directory are not relevant. I am compiling with the explicit include path from 'root-config --cflags', which gives -I/opt/local/libexec/root6/include/root, the correct directory.

I think this may actually be an upstream bug with ROOT, if the RConfig.h symlink is created by ROOT and not by Macports. That or clang is not resolving the symlink when it should be. What is the expected behaviour here?

I can also "fix" the problem by removing the RConfig.h symlink altogether and editing the TreeBuilderDictionary.cc file to explicity include ROOT/RConfig.h instead of RConfig.h. However, this file is generated by rootcling, which should know better than to include the wrong file...

[cjones051073 (Chris Jones)]

It would not be the first time root generated code it could not compile....

can you make a simple reproducer ?

Also, before reporting upstream I would want to see if it occurs with the binary distribution upstream provide, to first rule out a packaging issue in macports.

[lpgaff (Liam Gaffney)]

I don't have a simple reproducer, but I have the full code (not so big) on GitHub at ​https://github.com/Miniball/MiniballCoulexSort

Just try make in the top level directory or in the TreeBuilder directory to see it fail on the dictionary compilation.

[mascguy (Christopher Nielsen)]

Replying to lpgaff:

I don't have a simple reproducer, but I have the full code (not so big) on GitHub at ​https://github.com/Miniball/MiniballCoulexSort

Just try make in the top level directory or in the TreeBuilder directory to see it fail on the dictionary compilation.

Is this still an issue?

[lpgaff (Liam Gaffney)]

Replying to mascguy:

Replying to lpgaff:

I don't have a simple reproducer, but I have the full code (not so big) on GitHub at ​https://github.com/Miniball/MiniballCoulexSort

Just try make in the top level directory or in the TreeBuilder directory to see it fail on the dictionary compilation.

Is this still an issue?

No, I don't think so. It must have been fixed in some update of ROOT.