Possible REFLEX_GENERATE_DICTIONARY c++ standard mismatch

chilgenb · July 6, 2021, 2:20pm

I am trying to switch to using REFLEX_GENERATE_DICTIONARY from ROOT_GENERATE_DICTIONARY. The latter seems to work fine, while using the former results in an error that is consistent with a c++ standard mismatch. Namely,

no type named 'string_view' in namespace 'std'

I built ROOT v6.24/00 from source with Python3 and the c++17 standard. From my root-config, I have

root-conifig --cflags
-pthread -std=c++17 -m64 -I/usr/local/root/root_install/include

and

root-config --python-version
3.8.5

Has anyone else seen this?

Please read tips for efficient and successful posting and posting code

_ROOT Version: 6.24/00
_Platform: Ubuntu 20.04
_Compiler: gcc 9.3.0

eguiraud · July 6, 2021, 2:32pm

Hi @chilgenb ,
and welcome to the ROOT forum! Indeed I don’t think that REFLEX_GENERATE_DICTIONARY is on par with ROOT_GENERATE_DICTIONARY. We usually suggest to use the latter. Why are you trying to switch?

@amadio feel free to chime in if you have more info.

Cheers,
Enrico

chilgenb · July 6, 2021, 3:29pm

Thank you @eguiraud for the kind welcome!

The reason for the switch is to be consistent with common build tools being used by Fermilab experiments/projects, LArSoft for example. These build tools use REFLEX_GENERATE_DICTIONARY, though the reason for this is not entirely clear to me. It would be great if I didn’t have to provide support for using both macros.

Wile_E_Coyote · July 6, 2021, 3:39pm

You may have more luck if you build ROOT with the “c++14” standard (or, in the worst case, “c++11”).

eguiraud · July 6, 2021, 3:59pm

Uhm, our fault for not officially deprecating REFLEX_GENERATE_DICTIONARY, I guess

I think we would need to be able to reproduce the issue on our side to properly debug this. Would you be able to provide a minimal reproducer?

Cheers,
Enrico

Axel · July 7, 2021, 7:42am

We have several experiments relying on REFLEX_GENERATE_DICTIONARY

The error you report is bad - I will need to see why our tests don’t pick this up! I’ll be back, please ping me end of the week if you haven’t heard from me.

chilgenb · July 8, 2021, 1:42am

reflexgen_debug.tar.gz (1.3 KB)

Here is a minimal working example. I believe the problem comes down to my trying to do a local build+install, requiring root permissions.

This works (from a parallel build directory):

$ cmake ../reflexgen
$ cmake --build .
$ sudo cmake --install .

However, this does not:

$ cmake ../reflexgen
$ sudo cmake --build . --target install

I verified that I get the same result with either sequence when using ROOT_GENERATE_DICTIONARY. It appears that going to su changes the c++ standard for the compiler only when using REFLEX_GENERATE_DICTIONARY.

In addition, I find that ROOT_GENERATE_DICTIONARY and REFLEX_GENERATE_DICTIONARY are inconsistent with respect to the write location and naming of the rdict.pcm and .rootmap files.

${CMAKE_LIBRARY_OUTPUT_DIRECTORY} is the default for ROOT_GENERATE_DICTIONARY, while ${CMAKE_BINARY_DIR} is the default for REFLEX_GENERATE_DICTIONARY.

With the dictionary target name, ${DICTIONARY_TARGET_NAME}, the .rootmap file is named ${DICTIONARY_TARGET_NAME}.rootmap with ROOT_GENERATE_DICTIONARY, while it is named ${DICTIONARY_TARGET_NAME}Dict.rootmap with REFLEX_GENERATE_DICTIONARY.

Best,
Chris

Axel · July 8, 2021, 12:26pm

Hi Chris,

The dictionary will match the standard used to build ROOT. To use a dictionary of C++14 classes, ROOT itself must be built with C++14. Can we make sure that’s the case? It might be that sudo cmake --build . --target install pulls in a different ROOT. You can probably try by doing sudo root -q -e __cplusplus. What’s the output?

chilgenb · July 8, 2021, 2:46pm

Hi @Axel,

It appears you are correct! I get

$ sudo root -q -e __cplusplus

Warning in <TInterpreter::ReadRootmapFile>: class  garana::CaloCluster found in libG__GaranaDictDict.so  is already in libGaranaDict.so 
Warning in <TInterpreter::ReadRootmapFile>: class  garana::FSParticle found in libG__GaranaDictDict.so  is already in libGaranaDict.so 
Warning in <TInterpreter::ReadRootmapFile>: class  garana::G4Particle found in libG__GaranaDictDict.so  is already in libGaranaDict.so 
Warning in <TInterpreter::ReadRootmapFile>: class  garana::GTruth found in libG__GaranaDictDict.so  is already in libGaranaDict.so 
Warning in <TInterpreter::ReadRootmapFile>: class  garana::Track found in libG__GaranaDictDict.so  is already in libGaranaDict.so 
Warning in <TInterpreter::ReadRootmapFile>: class  garana::Vee found in libG__GaranaDictDict.so  is already in libGaranaDict.so 
Warning in <TInterpreter::ReadRootmapFile>: class  garana::Vertex found in libG__GaranaDictDict.so  is already in libGaranaDict.so 
   ------------------------------------------------------------------
  | Welcome to ROOT 6.22/06                        https://root.cern |
  | (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Apr 19 2021, 20:22:00                 |
  | From tags/v6-22-06@v6-22-06                                      |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |
   ------------------------------------------------------------------


(long) 201103

I am confused, however, how this only happens when I use REFLEX_GENERATE_DICTIONARY.

Axel · July 8, 2021, 2:54pm

So you have two ROOT installs. One is accessible to the super user e.g. because it’s in $PATH, the other one to your user; the latter us used when your user builds.

If you were to invoke genreflex yourself, sudo and non-sudo would pick up different binaries. I’m not sure I understand what this has to do with REFLEX_GENERATE_DICTIONARY, other than that it triggers this.

I guess the solution is to make sure that your build uses the ROOT you expect. It would be good if REFLEX_GENERATE_DICTIONARY would be forced to use a given ROOT build, as provided by find_package(ROOT) at configuration time. This seems to be a bug. It’d be great if @bellenot could look at this once he is back!

chilgenb · July 8, 2021, 3:00pm

I confirm that this older install (v6.22/06) of ROOT that sudo cmake finds was build with -std=c++11 .

Oddly enough, specifying the minimum ROOT version in the top level cmake file to be v6.24/00 does not alleviate the problem.

Axel · July 8, 2021, 3:13pm

That just gets you past find_package. But that succeeds - and its output / result is then ignored by REFLEX_GENERATE_DICTIONARY :-/

eguiraud · July 12, 2021, 2:10pm

Hi all,
I guess we want to turn this into a bug report for @bellenot at Issues · root-project/root · GitHub ?

bellenot · July 12, 2021, 2:12pm

Yes, please feel free to open a Github issue for this

system · July 26, 2021, 2:12pm

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.