Unresolved symbols when using std::async

[berserker]

I tried to post the bug to Jira, but CERN OAuth page tells me invalid_request when I try to log in there.

So, I am using root_v6.12.06.Linux-ubuntu17-x86_64-gcc7.2.tar.gz, the official binaries. I did want to speed up my code a lil bit with std::async and got such errors:

IncrementalExecutor::executeFunction: symbol '__emutls_v._ZSt11__once_call' unresolved while linking function '_GLOBAL__sub_I_cling_module_8'!
IncrementalExecutor::executeFunction: symbol '__emutls_v._ZSt15__once_callable' unresolved while linking function '_GLOBAL__sub_I_cling_module_8'!

That’s all I did want to say.
Thank you.

[Axel]

That’s weird, thanks for reporting! I have created https://sft.its.cern.ch/jira/browse/ROOT-9277

[berserker]

Or I just have some dependencies missing?

[Axel]

I don’t know, I don’t think so…

[Danilo]

I missed that you are using ROOT and not cling stand alone: apologies.

We provide also ROOT::Experimental::Async: can this maybe unblock you until we figure out what this is about?

Cheers,
D

[berserker]

@Danilo

We provide also ROOT::Experimental::Async: can this maybe unblock you until we figure out what this is about?

It uses std::async internally, isn’t it? So I see the same error if I try to use ROOT::Experimental::Async.
From my comment in JIRA:

[~/software/root/tutorials/multicore]
user@host $ root mt303_AsyncSimple.C 
root [0] 
Processing mt303_AsyncSimple.C...
IncrementalExecutor::executeFunction: symbol '__emutls_v._ZSt11__once_call' unresolved while linking [cling interface function]!
IncrementalExecutor::executeFunction: symbol '__emutls_v._ZSt15__once_callable' unresolved while linking [cling interface function]!
root [1] .q

ROOT::Experimental::Async works if I compile macros, i.e. run them with +, this currently unblocks me.

[Danilo]

Hi @berserker,

thanks for trying this out so quickly. No, actually the implementation is orthogonal: ROOT::Experimental::Async leverages on the internal pool of workers of ROOT w/o any risk to overcommit the machine.
What it uses internally is a std::future which I think is the missing piece. I remember that in older versions of clang on which we based ROOT did not support it because of the usage of TLS. And I also remember that this was fixed around late summer upstream in clang

Cheers,
Danilo