root6 port results in ambiguous include directories after 6.14

[olupton (Olli Lupton)]

With the most recent verison(s) of the root6 port I have had problems compiling local code linking against ROOT.

The problem seems to be that in the default MacPorts installation of root6 the ROOT headers are accessible both at /opt/local/libexec/root6/include/root (returned by root-config --incdir) and /opt/local/include/root{,6}

And since 6.14 at least one header with the same name exists at multiple levels of the header file structure:

MD5 (/opt/local/libexec/root6/include/root/RConfig.h) = c2c2d44a3228fcbf9943048bfca2cb27
MD5 (/opt/local/libexec/root6/include/root/ROOT/RConfig.h) = 5d2a7a998a363947acd947487a666bea

(see e.g. ​https://root.cern.ch/doc/v614/ROOT_2RConfig_8h.html and the non-existence of the same page for 6.12)

When (automatically-generated) code tries to include the latter, i.e. #include <ROOT/RConfig.h>, then, if /opt/local/include is in the include path, /opt/local/include/root/RConfig.h is found instead (with a warning about non-portable filenames because the case doesn't match, -Wnonportable-include-path), and compilation fails because the wrong one of the two RConfig.h is picked up (errors like error: use of undeclared identifier 'R__likely' -- included so hopefully Google finds this ticket).

A minimal workaround is to remove the /opt/local/include/root symlink and make sure /opt/local/libexec/root6/include/root is in the include path for compilation. This seems a bit ugly, but so do all the other solutions...

It seems that the /opt/local/include/root6 link always exists, but /opt/local/include/root depends on having run port select root root6.

Possibilities I see:

• Remove /opt/local/include/root symlink: seems wrong to not have the headers somewhere under /opt/local/include
• Move the headers one directory up the tree under /opt/local/include, i.e. ln -s /opt/local/libexec/root6/include/root/RConfig.h /opt/local/include/RConfig.h repeated for every ROOT header: involves a large number of links, but does integrate ROOT into the /opt/local tree a bit better.
• Consider it a bug on my part that /opt/local/include is in the include path when compiling against ROOT: seems unreasonable, many other packages' headers are only available here.
• Consider it a bug on my part that /opt/local/include comes before /opt/local/libexec/root6/include in the include path: doesn't seem very robust/reasonable to expect all external dependencies to respect this convention

[mf2k (Frank Schima)]

In the future, please add the port maintainer(s) to Cc (port info --maintainers root6), if any.

[cjones051073 (Chris Jones)]

Hi Oli !!!

Hmm, interesting. In terms of modifying what the port does I don't like either of your first two suggestions.

My initial reaction, based on the content of the two files is simply to forcibly remove

/opt/local/libexec/root6/include/root/RConfig.h

as this is simply a forwarding header to

/opt/local/libexec/root6/include/root/ROOT/RConfig.h

and based on a comment in the file, the later should simply always be used.

[cjones051073 (Chris Jones)]

Actually, its been on my to do list to consider not auto port selecting root{5,6} for the user, as this practise has been criticised a few times. You could also try removing this yourself

  port select root none

to see if that helps. Of course then you will have to use the versioned executables etc.

[cjones051073 (Chris Jones)]

A better idea. Instead of removing

/opt/local/libexec/root6/include/root/RConfig.h

replace it with a sym link to

/opt/local/libexec/root6/include/root/ROOT/RConfig.h

I think the issue you are seeing is due to the OSX case insensitive file system which you include the first file, it tries to forward include the second, but instead just includes the first again (which does nothing) so in the end nothing is included. The sym link should fix this...

[olupton (Olli Lupton)]

Hi Chris!

First of all, I agree with your description of what the problem is (the forwarding header includes itself and achieves nothing).

OK, so

port select root none

also avoids the problem (which makes sense). This is a bit unsatisfactory though, there are plenty of scripts that assume root and root-config are called just that.

Removing /opt/local/libexec/root6/include/root/RConfig.h nearly works, but, amusingly, fails because the dictionary code that ROOT generates for custom classes (as produced by ROOT's ROOT_GENERATE_DICTIONARY CMake macro) actually contains #include "RConfig.h" instead of `#include "ROOT/RConfig.h".

Your final suggestion, making /opt/local/libexec/root6/include/root/RConfig.h a symlink to /opt/local/libexec/root6/include/root/ROOT/RConfig.h, seems to work fine.

Hopefully ROOT's plans to put more headers under ROOT/ (​https://root.cern.ch/blog/rootrwhy) don't lead to more clashes like this.

[Chris Jones <jonesc@…>]

In 7cbc6ba8b04ba73986d7e5aed87b9ff007861322/macports-ports (master):

root6: Add workaround for ambiguous header resolution

Closes: #57007

[cjones051073 (Chris Jones)]

If more headers migrate to ROOT/ over time then yes I might need to rethink the packaging that the port does to avoid the naming clash. Until then this workaround fixes things, for now.

[olupton (Olli Lupton)]

Thanks for committing the workaround, I updated to use it and it now works fine out of the box.

[henryiii (Henry Schreiner)]

This has now been fixed in the ROOT sources, and the patch will no longer be needed in ROOT 6.16.02. See the homebrew PR ​https://github.com/Homebrew/homebrew-core/pull/36585 for more information and links to the ROOT PR.

[hansgans]

I'm encountering the same errors as OP with the current version (6.16.00):

/opt/local/libexec/root6/include/root/TStorage.h:86:4: error: use of undeclared identifier 'R__likely'
   ClassDef(TStorage,0)  //Storage manager class`

I set ROOTSYS to /opt/local/libexec/root6. But this makes no difference compared to /opt/local/.

[cjones051073 (Chris Jones)]

please provide a minimal reproducer for the issue.

[hansgans]

Reinstalling the port solved it. Sorry for the noise.