Cling (Clang-13) compile errors on Ubuntu 22.04, using ubuntu clang++14

Hello,

I am using ROOT’s cling to write a textbook and was curious to see whether I could build it myself, first in Linux and then possibly using Termux. I used the script on the Cling Build Instructions page to build:

clang version 13.0.0 (http://root.cern.ch/git/clang.git 25f804797f80b69d8c56794e3e0300acd9458958) (http://root.cern.ch/git/llvm.git ac712f0f44b45a1455a302dd6cbb7b6cce269d2d)

on Ubuntu 22.04 using:

Ubuntu clang version 14.0.0-1ubuntu1.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Two errors were reported:

  1. cling/lib/Interpreter/DeclUnloader.cpp:1031:55: error: ‘class clang::FunctionTemplateDecl’ has no member named ‘loaded_spec_begin’
  2. cling/lib/Interpreter/DeclUnloader.cpp:1044:52: error: ‘class clang::ClassTemplateDecl’ has no member named ‘loaded_spec_begin’

I searched all downloaded files for loaded_spec_begin and found there was no definition either within cling or within llvm but there were: spec_begin() and spec_end(). Replacing loaded_spec_begin() and loaded_spec_end() with these resulted in a functional system, except when compiling a macro where it crashes after reporting a correctly identified error. The commands were:

cling -std=c++17 # bash
// in cling:
[cling]$ .L lch.cpp 
In file included from input_line_3:1:
/media/mark/07973540357/mark/Documents/Code/functional-cpp/code-examples/chapter-01/lch.cpp:152:15: error: implicit instantiation of undefined template 'std::basic_ifstream<char>'
    auto in = std::ifstream{
              ^
/usr/include/c++/11/iosfwd:116:11: note: template is declared here
    class basic_ifstream;
          ^
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
cling(+0x13c3e15)[0x55596dda8e15]
cling(+0x13c164e)[0x55596dda664e]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7fa1c5842520]
cling(_ZN5clang11DeclContext10removeDeclEPNS_4DeclE+0x144)[0x55596fb89324]
cling(_ZN5cling12DeclUnloader14VisitNamedDeclEPN5clang9NamedDeclE+0x166)[0x55596dc34186]
cling(_ZN5cling12DeclUnloader18VisitNamespaceDeclEPN5clang13NamespaceDeclE+0x113)[0x55596dc3d703]
cling(_ZN5cling12DeclUnloader16VisitDeclContextEPN5clang11DeclContextE+0x130)[0x55596dc3d030]
cling(_ZN5cling12DeclUnloader20VisitLinkageSpecDeclEPN5clang15LinkageSpecDeclE+0x40)[0x55596dc3d480]
cling(_ZN5cling19TransactionUnloader18unloadDeclarationsEPNS_11TransactionERNS_12DeclUnloaderE+0x10c)[0x55596dccca6c]
cling(_ZN5cling19TransactionUnloader17RevertTransactionEPNS_11TransactionE+0x207)[0x55596dccccf7]
cling(_ZN5cling11Interpreter6unloadERNS_11TransactionE+0x216)[0x55596dca3e16]
cling(_ZN5cling17IncrementalParser17commitTransactionERN4llvm14PointerIntPairIPNS_11TransactionELj2ENS0_12EParseResultENS1_21PointerLikeTypeTraitsIS4_EENS1_18PointerIntPairInfoIS4_Lj2ES7_EEEEb+0x377)[0x55596dc98227]
cling(_ZN5cling17IncrementalParser7CompileEN4llvm9StringRefERKNS_18CompilationOptionsE+0x6a)[0x55596dc9ce3a]
cling(_ZN5cling11Interpreter10loadHeaderERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPPNS_11TransactionE+0x1e8)[0x55596dca3b28]
cling(_ZN5cling8MetaSema13actOnLCommandEN4llvm9StringRefEPPNS_11TransactionE+0x19c)[0x55596dcf4aac]
cling(_ZN5cling10MetaParser9isCommandERNS_8MetaSema12ActionResultEPNS_5ValueE+0x100)[0x55596dced250]
cling(_ZN5cling13MetaProcessor7processEN4llvm9StringRefERNS_11Interpreter17CompilationResultEPNS_5ValueEb+0x1e0)[0x55596dcedf70]
cling(_ZN5cling13UserInterface16runInteractivelyEb+0x272)[0x55596ddcd0b2]
cling(main+0xab5)[0x55596dad7565]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7fa1c5829d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7fa1c5829e40]
cling(_start+0x25)[0x55596dbab0e5]
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.	Program arguments: cling -std=c++17

So I have a couple of questions:

  1. is the fix for loaded_spec_begin() and loaded_spec_end() correct?
  2. is the above crash sufficient for you to diagnose the problem?

BTW: based on a previous report about the same error occurring on WSL, I changed the build command to:

cmake 
	-DCMAKE_BUILD_TYPE=Release 
	-DLLVM_BUILD_TOOLS=Off 
	-DCMAKE_INSTALL_PREFIX=$INSTDIR 
	-DPYTHON_EXECUTABLE=$python 
	-DLLVM_EXTERNAL_PROJECTS=cling 
	-DLLVM_EXTERNAL_CLING_SOURCE_DIR=../src/tools/cling 
	-DLLVM_ENABLE_PROJECTS=clang 
	-DLLVM_TARGETS_TO_BUILD="host;NVPTX" ../src 
	> /dev/null || exit 1   

in the build script.

Many thanks,
Marv

Hi @marvin_littlewood,

thank you for the question. Maybe @Axel could help with these questions?

Cheers,
Marta

Thank you @mczurylo.

@Axel: here is some more info…

I tried setting the environment variable to the path for llvm-symbolizer, per the instructions in the crash report. Sadly it didn’t make much difference to the output. However the same report occurs whenever there is an error in the code parsed by the .L command.

FWIW lch.cpp works when using ROOT 6.28/06, but I prefer cling for teaching purposes. It spotted a couple of missing include files that only compilation would otherwise have found.

Marv

PS:
I tested cling on some other macro files that ROOT compiled without complaint. It seems that the crash report only occurs when there is a missing header file. Other errors such as duplicate symbol names at the same scope are reported without a crash.

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