RDataFrame and userdefined event classes on Windows - Problem with string expressions


ROOT Version: 6.18.04
Platform: Windows 10
Compiler: MVC 2019 Build 14.23.28105, Host=x64, Platform=x86


Hi everybody,

first of all, I did quite a lot of root builds on different Desktop PCs since the announcement at the root user meeting last year.
Thanks to Bertrand I learned many details of this process. Many issues that I observed seem to be resolved in the latest version except for example the imt package which uses an older SDK and causes thus build errors.
Anyway, my problem is a different one:

I build up a framework which uses ROOT IO functionality for userdefined event classes. The framework is primarily developed for linux and macos platforms but every now and then I checked the windows version since we have more windows than linux users. Our workaround so far is therefore SWAN which is nice but extremely slow due to EOS and the use of relative large files.
RDataFrame is primarily used for the data evaluation which allows use a very compact and flexible way of defining an analysis.
It works pretty fine on linux and macos and has been tested already with many different gcc versions and clang1000.
However, for the VC++ compiler under Windows I observed since 6.14 up to now always the same runtime errors for which I provide you a minimum reproducer.

You may wonder, why I’m building ROOT on windows myself. If I don’t, I’d just get more runtime errors as you can see in the attached log files when building the libraries of my framework (prebuild.log and ownbuild.log).

For a detailed description of the reproducer example, please refer to


which uses the same example but discuss another issue on linux that was resolved some time ago.

For the present issue on Windows please download the source files, build commands (Makefile.bat) and logfiles from here:

rdf_win.zip (3.2 KB)

The error occurs when using strings which are compiled at run time for filters or defines of RDataFrame.
Example:

auto df = d.Filter("b0.getVal() < 5");

where the column b0 is related to objects of a userdefined class that is dederived from TObject (testclass).

The error which seem to occure only on Windows is as follows:

IncrementalExecutor::executeFunction: symbol '_Init_thread_abort' unresolved while linking [cling interface function]!
You are probably missing the definition of _Init_thread_abort
Maybe you need to load the corresponding shared library?

After plenty ROOT builds on Windows, tests on different hardware and comparison with prebuilds, I’m pretty sure that this must be a bug.
Please, let me know if you can reproduce this error.

Many thanks in advance,
Kai

Hi Kai,

First, that might well be a known issue, there are still several RDataFrame tests failing on Windows. But I’ll try nevertheless and I’ll let you know.

I don’t see any problem with the builtin_tbb option (if it’s what you’re referring to)

Cheers,
Bertrand.

OK, so here is what I tried (with ROOT master). Note the compilation flags:

C:\Users\bellenot\rootdev\forum\rdf_win>rootcint -f G__testclass.cxx testclass.hxx testclassLinkDef.h
C:\Users\bellenot\rootdev\forum\rdf_win>cl /nologo /Z7 /MD /GR /EHsc -I%ROOTSYS%\include main.cpp testclass.cxx G__testclass.cxx /link -LIBPATH:%ROOTSYS%\lib libCore.lib libRIO.lib libNet.lib libHist.lib libGraf.lib libGraf3d.lib libGpad.lib libROOTVecOps.lib libTree.lib libTreePlayer.lib libRint.lib libPostscript.lib libMatrix.lib libPhysics.lib libMathCore.lib libThread.lib libROOTDataFrame.lib libGui.lib /out:main.exe
main.cpp
C:\Users\bellenot\build\debug\include\ROOT\libcpp_string_view.h(193): warning C4068: unknown pragma
testclass.cxx
G__testclass.cxx
C:\Users\bellenot\build\debug\include\ROOT\libcpp_string_view.h(193): warning C4068: unknown pragma
Generating Code...

C:\Users\bellenot\rootdev\forum\rdf_win>main
Warning in <TClassTable::Add>: class ROOT::Detail::TTypedIter<class TEnumConstant> already in TClassTable
fUniqueID
fBits
TObject
a
b0
5 entries passed all filters

C:\Users\bellenot\rootdev\forum\rdf_win>

Is that what you get on other platforms?

Hi Bertrand,

this is what I’d love to see but I never got to this point. Please have a look into the logfiles. Whether debug or release version, ROOT pre-builds from the download page or own builds there is always at least the runtime error that I described above. The build process is identical to yours. No problems with building at least.

Do you use the following environment before running the build commands?
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars32.bat"

FYI, I started from a fresh NICE installation with having only Visual Studio 2019. Do you have a chance to test it on a clean PC?

Cheers,
Kai

Looking at your log files, the obvious problem is that you’re not using the same version of Window 10 SDK than ROOT (10.0.18362.0 vs 10.0.17763.0)

And here is what I did:
Using Visual Studio 2019 v16.3.7, starting from a x86 Native Tools Command Prompt for VS 2019, (so no need to call vcvars32.bat) and I built ROOT in Debug mode:

cmake --build . --config Debug

Important! I use the following compiler flags to build your test:

cl /nologo /Z7 /MD /GR /EHsc 

Well, I could set-up a Virtual Machine, but if I can avoid this… I would prefer to make sure you solve the issue you have on your side first

So I managed to reproduce the issue with the pre-built version 6.18.04 (dbg). I’m now building it from source to see if it’s only due to the different versions of the SDK, but it might be due to a bug which has been fixed in the master…

Hi Bertrand,

This would explain why I also had to manually build the tbb library instead of using the builtin_tbb option. Is there an option to chose a specific sdk when installing VS?
I actually bypass this error when using my own ROOT build (ownbuild.log).

However are you sure that you reproduce also the same error as mentioned above:

IncrementalExecutor::executeFunction: symbol '_Init_thread_abort' unresolved while linking [cling interface function]!
You are probably missing the definition of _Init_thread_abort
Maybe you need to load the corresponding shared library?

This one and very similar once you will find further down in both logfiles.

I tried the pre-builts of v6.18.04 both release and debug as well as an own built of v6.18.04 release. With the latter one, I don’t get anymore the error related to different SDK’s but the cling error remains.

Kai

Hi Kai,

I confirm that ROOT v6.18.04 (built from source) produces the following errors:

C:\Users\bellenot\rootdev\forum\rdf_win>main
Warning in <TClassTable::Add>: class ROOT::Detail::TTypedIter<class TEnumConstant> already in TClassTable
fUniqueID
fBits
TObject
a
b0
IncrementalExecutor::executeFunction: symbol '_Init_thread_abort' unresolved while linking [cling interface function]!
You are probably missing the definition of _Init_thread_abort
Maybe you need to load the corresponding shared library?
IncrementalExecutor::executeFunction: symbol '_Init_thread_epoch' unresolved while linking [cling interface function]!
You are probably missing the definition of _Init_thread_epoch
Maybe you need to load the corresponding shared library?
IncrementalExecutor::executeFunction: symbol '_Init_thread_header' unresolved while linking [cling interface function]!
You are probably missing the definition of _Init_thread_header
Maybe you need to load the corresponding shared library?
IncrementalExecutor::executeFunction: symbol '_tls_index' unresolved while linking [cling interface function]!
You are probably missing the definition of _tls_index
Maybe you need to load the corresponding shared library?
IncrementalExecutor::executeFunction: symbol '_Init_thread_footer' unresolved while linking [cling interface function]!
You are probably missing the definition of _Init_thread_footer
Maybe you need to load the corresponding shared library?

So please use the master instead (with the builtin_tbb and dataframe options enabled).

Yes, in the Visual Studio Installer, select Modify, and then in the Installation Details (on the right hand side), you can select which Windows 10 SDK you want to install.

Cheers, Bertrand.

Hi Bertrand,

that’s great! I’ve got it also working using the master. Thanks a lot for your help.

builtin_tbb causes still problems during building even after modifying the SDK. The tbb log states that the SDK could not be found. However, it works with manually building the tbb libraries and referring to them when building ROOT. Next time when I get a chance to start from a fresh windows installation I’ll chose directly the specific SDK.

The issue is resolved.

Cheers,
Kai

1 Like

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