[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