[MacPorts] #57654: root6 port has header problems in 6.14/06
MacPorts
noreply at macports.org
Tue Nov 20 17:05:23 UTC 2018
#57654: root6 port has header problems in 6.14/06
----------------------+--------------------
Reporter: olupton | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------
Old description:
> 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...
New description:
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...
--
Comment (by olupton):
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...
--
Ticket URL: <https://trac.macports.org/ticket/57654#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list