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?

1 Like

@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

1 Like

@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”.

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