Closed levy closed 10 months ago
Yes, this is known: the JIT in the current version of LLVM underlying Cling uses emulated TLS even if the platform supports it natively. More recent gcc no longer does that and so linking will fail. Have to see whether this improves with LLVM13 (upstream has ported Cling, is now fixing up the last failing tests). Certainly JITLink supports TLS.
Thanks for the heads up.
A simpler example to check/reproduce the bug:
import cppyy
cppyy.cppdef("class Foo { static thread_local int x; public: static int getX() {return x;} }; int thread_local Foo::x;")
cppyy.gbl.Foo.getX() # IncrementalExecutor::executeFunction: symbol '__emutls_v._ZN3Foo1xE' unresolved while linking symbol '__cf_5'!
When deleting the two thread_local
modifiers, the error goes away. It also goes away if getX()
is changed to be out-of-line:
import cppyy
cppyy.cppdef("class Foo { static thread_local int x; public: static int getX(); }; int thread_local Foo::x; int Foo::getX() {return x;}")
cppyy.gbl.Foo.getX() #ok
Missed this bug report somehow ... the thread_local
has been fixed since 3.0.0 (which uses Clang13).
If I change the function to be out-of-line, then it works.
pip3 list
test.h
test.cc
test_thread_local.py
compiling
running