Opened 6 years ago
Last modified 5 years ago
#57654 closed defect
root6 port has header problems in 6.14/06 — at Version 2
Reported by: | olupton (Olli Lupton) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.5.4 |
Keywords: | Cc: | mojca (Mojca Miklavec), cjones051073 (Chris Jones) | |
Port: | root6 |
Description (last modified by olupton (Olli Lupton))
It seems that there is a problem with the include paths in the newest (6.14/06) version of ROOT.
This is closely related to https://trac.macports.org/ticket/57007 -- the resolution to that was to make
/opt/local/libexec/root6/include/root/RConfig.h
a symbolic link to /opt/local/libexec/root6/include/root/ROOT/RConfig.h
.
The new problem is that /opt/local/libexec/root6/include/root/ROOT/RConfig.h
now contains #include "../RVersion.h"
, which is intended to resolve to /opt/local/libexec/root6/include/root/RVersion.h
. If the include path is such that #include "RConfig.h"
picks up the symbolic link then compilation fails:
/opt/local/libexec/root6/include/root/RConfig.h:22:10: fatal error: '../RVersion.h' file not found #include "../RVersion.h" ^~~~~~~~~~~~~~~ 1 error generated.
This change to RConfig.h
was introduced in
https://github.com/root-project/root/commit/38580d360a3c1793e5cc8af1c9e9efbba71f9b74#diff-9361ac3923df05c6c743e0822e6fe33e
Reverting the change, so RConfig.h
contains #include "RVersion.h"
, worked for me as a temporary hack. I don't immediately see a nice solution...
Change History (2)
comment:1 Changed 6 years ago by cjones051073 (Chris Jones)
comment:2 Changed 6 years ago by olupton (Olli Lupton)
Description: | modified (diff) |
---|
That didn't work:
ccache /opt/local/bin/clang++ -DCustomRoot_EXPORTS -DR__HAVE_CONFIG -DWITH_TBB -Iinclude -isystem explicit/include -isystem range-v3/include -isystem /opt/local/libexec/root6/include/root -isystem /opt/local/include -pipe -Os -stdlib=libc++ -m64 -pipe -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++1z -stdlib=libc++ -DR__HAVE_CONFIG -O2 -g -DNDEBUG -fPIC -Wall -Weverything -pedantic -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-missing-prototypes -Wno-global-constructors -Wno-padded -Wno-conversion -Wno-double-promotion -Wno-weak-vtables -Wno-exit-time-destructors -Wno-float-equal -Wno-used-but-marked-unused -Wno-undefined-func-template -std=c++17 -Wno-old-style-cast -Wno-unused-macros -Wno-reserved-id-macro -Wno-zero-as-null-pointer-constant -MD -MT src/CMakeFiles/CustomRoot.dir/CustomRootDicts.cxx.o -MF src/CMakeFiles/CustomRoot.dir/CustomRootDicts.cxx.o.d -o src/CMakeFiles/CustomRoot.dir/CustomRootDicts.cxx.o -c src/CustomRootDicts.cxx In file included from src/CustomRootDicts.cxx:12: In file included from /opt/local/include/ROOT/RConfig.h:1: /opt/local/include/ROOT/RConfig.h:1:15: fatal error: 'ROOT/RConfig.h' file not found #include_next <ROOT/RConfig.h> ^~~~~~~~~~~~~~~~ 1 error generated.
I think the original #include "RConfig.h"
finds /opt/local/libexec/root6/include/root/RConfig.h
(contents: #include_next
), which then looks for ROOT/RConfig.h
starting from the next directory in the include search list (/opt/local/include
) and finds /opt/local/include/root/RConfig.h
...which is the same file containing #include_next
. But 2nd time there are no more search paths to try, so it fails.
If I use #include
instead of #include_next
in the wrapper header then my current test case compiles. Not sure if that will break in some other case though...
The ROOT devs are really going out of their way to make this difficult...
Frankly, I view this as a flaw in the way the package their headers upstream, its a real spagetti mess right now.
Maybe though, there is something you could try. Could you remove the sym link
/opt/local/libexec/root6/include/root/RConfig.h
and instead make it a wrapper header that has in it just
and see how things fair with that ?