Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#57007 closed defect (fixed)

root6 port results in ambiguous include directories after 6.14

Reported by: olupton (Olli Lupton) Owned by: cjones051073 (Chris Jones)
Priority: Normal Milestone:
Component: ports Version: 2.5.3
Keywords: Cc: mojca (Mojca Miklavec)
Port: root6

Description (last modified by 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

Change History (14)

comment:1 Changed 6 years ago by olupton (Olli Lupton)

Description: modified (diff)

comment:2 Changed 6 years ago by olupton (Olli Lupton)

Description: modified (diff)

comment:3 Changed 6 years ago by mf2k (Frank Schima)

Cc: mojca added
Owner: set to cjones051073
Status: newassigned

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

comment:4 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by 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.

comment:6 Changed 6 years ago by 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...

comment:7 Changed 6 years ago by 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.

comment:8 Changed 6 years ago by Chris Jones <jonesc@…>

Resolution: fixed
Status: assignedclosed

In 7cbc6ba8b04ba73986d7e5aed87b9ff007861322/macports-ports (master):

root6: Add workaround for ambiguous header resolution

Closes: #57007

comment:9 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by olupton (Olli Lupton)

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

comment:11 Changed 5 years ago by 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.

comment:12 Changed 5 years ago by 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/.

comment:13 Changed 5 years ago by cjones051073 (Chris Jones)

please provide a minimal reproducer for the issue.

comment:14 Changed 5 years ago by hansgans

Reinstalling the port solved it. Sorry for the noise.

Note: See TracTickets for help on using tickets.