ROOT (master) compilation fails for libROOTNTuple.so in ubuntu 20.04

Hello!

I pulled latest ROOT master and tried to compile in Ubuntu 20.04 (x86-64) with g++ version 10.2.0, Python 3.8 (system default).
I used " cmake -DCMAKE_INSTALL_PREFIX=/usr/local/ROOT -DPYTHON_EXECUTABLE=/usr/bin/python3 -Dbuiltin_xrootd=ON …/ ".
While making, ROOT compilation crashed for “Linking CXX sgared library …/…/lib/libROOTNTuple.so” reporting
"/usr/bin/GCC10/…/ld: CMakeFiles/ROOTNTuple.dir/v7/src/RMiniFile.cxx.o: in function `ROOT::Experimental::Internal::RNTupleFileWriter::Commit()’: ".

Please suggest any handle.
Thanks and Regards
Abhijit Bhattacharyya


Please read tips for efficient and successful posting and posting code

ROOT Version: Not Provided
Platform: Not Provided
Compiler: Not Provided


Hi @vega,

The error from ld in your post seems truncated. Could you paste it here again, plus any other previous lines that seem like errors or warnings?

Cheers,
J.

Hi @jalopezg,
The error is reported as :

[ 82%] Linking CXX shared library …/…/lib/libTreePlayer.so
[ 82%] Built target TreePlayer
[ 82%] Built target G__ROOTNTuple
[ 82%] Linking CXX shared library …/…/lib/libROOTNTuple.so
/usr/bin/GCC10/…/ld: CMakeFiles/ROOTNTuple.dir/v7/src/RMiniFile.cxx.o: in function ROOT::Experimental::Internal::RNTupleFileWriter::Commit()': RMiniFile.cxx:(.text+0x2e28): undefined reference to TClass::GetClass(std::type_info const&, bool, bool)’
collect2: error: ld returned 1 exit status
make[2]: *** [tree/ntuple/CMakeFiles/ROOTNTuple.dir/build.make:379: lib/libROOTNTuple.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:31820: tree/ntuple/CMakeFiles/ROOTNTuple.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
vega@aditya:~/CERNSOFT/SOURCES/ROOT_GIT_SRC/build-ROOT$

Thanks

Hmmm… I think we are missing a dependency here (maybe -lCore), @jblomer?

BTW, @vega, can you confirm the git revision that you are trying to build?

@jalopezg , I pulled from master.

vega@aditya:~/CERNSOFT/SOURCES/ROOT_GIT_SRC/build-ROOT$ git describe --tags
v6-25-01-51-g664bb74def
vega@aditya:~/CERNSOFT/SOURCES/ROOT_GIT_SRC/build-ROOT$

I’m surprised that RNTuple is built at all without the explicit -Droot7. Are you sure that when calling cmake or make the environment did not include ROOT, i.e. echo $ROOTSYS was empty?

@jblomer sorry for late reply.

[ 82%] Built target TreePlayer
[ 82%] Built target G__ROOTNTuple
[ 82%] Linking CXX shared library ../../lib/libROOTNTuple.so
/usr/bin/GCC10/../ld: CMakeFiles/ROOTNTuple.dir/v7/src/RMiniFile.cxx.o: in function `ROOT::Experimental::Internal::RNTupleFileWriter::Commit()':
RMiniFile.cxx:(.text+0x2e28): undefined reference to `TClass::GetClass(std::type_info const&, bool, bool)'
collect2: error: ld returned 1 exit status
make[2]: *** [tree/ntuple/CMakeFiles/ROOTNTuple.dir/build.make:379: lib/libROOTNTuple.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:31820: tree/ntuple/CMakeFiles/ROOTNTuple.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
vega@aditya:~/CERNSOFT/SOURCES/ROOT_GIT_SRC/build-ROOT$ echo $ROOTSYS

vega@aditya:~/CERNSOFT/SOURCES/ROOT_GIT_SRC/build-ROOT$ 

Yes I was also surprised to see that. Using ccmake ../ I observed root7 option is ON.

If you don’t need ROOT7 features, a quick workaround would be setting -Droot7=off. I’m still trying to understand what’s causing the actual issue.

@jblomer OK I am continuing with -Droot7=off. However, I see that “line 159” of the file cmake/modules/RootBuildOptions contains “root7 ON”. Also line 252 of the same file shows set(root7_defvalue ON). Are they anyway related?

@jblomer, well, I get following error with -Droot7=off

canning dependencies of target G__ROOTDataFrame
[ 83%] Building CXX object tree/dataframe/CMakeFiles/G__ROOTDataFrame.dir/G__ROOTDataFrame.cxx.o
[ 83%] Built target G__ROOTDataFrame
Scanning dependencies of target ROOTDataFrame
[ 83%] Building CXX object tree/dataframe/CMakeFiles/ROOTDataFrame.dir/src/RActionBase.cxx.o
[ 83%] Building CXX object tree/dataframe/CMakeFiles/ROOTDataFrame.dir/src/RCsvDS.cxx.o
[ 83%] Building CXX object tree/dataframe/CMakeFiles/ROOTDataFrame.dir/src/RDefineBase.cxx.o
[ 83%] Building CXX object tree/dataframe/CMakeFiles/ROOTDataFrame.dir/src/RCutFlowReport.cxx.o
[ 83%] Building CXX object tree/dataframe/CMakeFiles/ROOTDataFrame.dir/src/RDataFrame.cxx.o
[ 83%] Building CXX object tree/dataframe/CMakeFiles/ROOTDataFrame.dir/src/RDefineReader.cxx.o
[ 83%] Building CXX object tree/dataframe/CMakeFiles/ROOTDataFrame.dir/src/RDFActionHelpers.cxx.o
In file included from /home/vega/CERNSOFT/SOURCES/ROOT_GIT_SRC/tree/treeplayer/inc/TBranchProxy.h:22,
                 from /home/vega/CERNSOFT/SOURCES/ROOT_GIT_SRC/tree/treeplayer/inc/TTreeReaderUtils.h:26,
                 from /home/vega/CERNSOFT/SOURCES/ROOT_GIT_SRC/tree/treeplayer/inc/TTreeReader.h:26,
                 from /home/vega/CERNSOFT/SOURCES/ROOT_GIT_SRC/tree/dataframe/inc/ROOT/RDF/ActionHelpers.hxx:44,
                 from /home/vega/CERNSOFT/SOURCES/ROOT_GIT_SRC/tree/dataframe/src/RDFActionHelpers.cxx:11:
/home/vega/CERNSOFT/SOURCES/ROOT_GIT_SRC/core/cont/inc/TVirtualCollectionProxy.h:97:20: error: ‘ObjectPtr’ in ‘class TClass’ does not name a type
   97 |    virtual TClass::ObjectPtr NewObject() const {
      |                    ^~~~~~~~~
/home/vega/CERNSOFT/SOURCES/ROOT_GIT_SRC/core/cont/inc/TVirtualCollectionProxy.h:101:20: error: ‘ObjectPtr’ in ‘class TClass’ does not name a type
  101 |    virtual TClass::ObjectPtr NewObject(void *arena) const {
      |                    ^~~~~~~~~
/home/vega/CERNSOFT/SOURCES/ROOT_GIT_SRC/core/cont/inc/TVirtualCollectionProxy.h:114:20: error: ‘ObjectPtr’ in ‘class TClass’ does not name a type
  114 |    virtual TClass::ObjectPtr NewObjectArray(Int_t nElements) const {
      |                    ^~~~~~~~~
/home/vega/CERNSOFT/SOURCES/ROOT_GIT_SRC/core/cont/inc/TVirtualCollectionProxy.h:118:20: error: ‘ObjectPtr’ in ‘class TClass’ does not name a type
  118 |    virtual TClass::ObjectPtr NewObjectArray(Int_t nElements, void *arena) const {
      |                    ^~~~~~~~~
make[2]: *** [tree/dataframe/CMakeFiles/ROOTDataFrame.dir/build.make:141: tree/dataframe/CMakeFiles/ROOTDataFrame.dir/src/RDFActionHelpers.cxx.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:31276: tree/dataframe/CMakeFiles/ROOTDataFrame.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

That means DataFRame needs root7(?) Using root7=on explicitly or leaving it to follow default setup shows issue in libROOTNTuple.so.

Ok, something in this build tree is profoundly off. One option is to start with a fresh checkout of the sources and an empty build tree, again making sure that $ROOTSYS is unset before calling cmake. It might also be that you happen to have caught a broken master. Could you try with the latest release from the download page?

@oshadura Do you have perhaps a better idea how to debug this?

@jblomer, I deleted everything including all hidden .git*, .clang* etc files and freshly cloned from root. However, I see the same error.

[ 82%] Linking CXX shared library ../../lib/libROOTNTuple.so
/usr/bin/GCC10/../ld: CMakeFiles/ROOTNTuple.dir/v7/src/RMiniFile.cxx.o: in function `ROOT::Experimental::Internal::RNTupleFileWriter::Commit()':
RMiniFile.cxx:(.text+0x2e28): undefined reference to `TClass::GetClass(std::type_info const&, bool, bool)'
collect2: error: ld returned 1 exit status
make[2]: *** [tree/ntuple/CMakeFiles/ROOTNTuple.dir/build.make:379: lib/libROOTNTuple.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:31791: tree/ntuple/CMakeFiles/ROOTNTuple.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
vega@aditya:~/CERNSOFT/SOURCES/ROOT_GIT_SRC/build-Root$ git describe --tags
v6-25-01-71-ga680d48221
vega@aditya:~/CERNSOFT/SOURCES/ROOT_GIT_SRC/build-Root$ echo $ROOTSYS

vega@aditya:~/CERNSOFT/SOURCES/ROOT_GIT_SRC/build-Root$ 

Now I see that cloned distribution is v6-25-01-71 while later I see that the latest stable release is v6-22-06. Shall I checkout v6-22-06 instead of default master repo?

Yes, please try with v6-22-06

@jblomer, v6-22-06 has compiled without any error.

I think git master could point to v6-22-06 as default, latest stable build while git dev could point to v6-25-01-71 as latest developmental build. This could avoid confusion.
Thanks.

Thanks for confirming! Thanks for the suggestion, we can consider splitting between “head of development” and “latest stable”.