Cling failing on successive execution of compiled script

rwk7t · February 24, 2017, 4:35pm

Hi ROOT/Cling guys,

I’m used ROOT 5 extensively in the past and I’m just now starting to use ROOT6. I’m having two issues with the interpreter and ACLiC.

It seems that when I compile and execute some simple TTreeReader code, the 2nd time I execute in the same sessions I get an error. Specifically:

open ROOT interactive sessions:
[rwkelley@vector optimization]$ root

compile and execute macro:

root [0] .x cpp/reach.C++
Info in <TMacOSXSystem::ACLiC>: creating shared library /Users/rwkelley/temp/.rootbuild//Users/rwkelley/Development/dpm/research/optimization/./cpp/reach_C.so

Now it runs fine. So I run it again with no change to the source code and it errors:

root [1] .x cpp/reach.C++
Info in <ACLiC>: unmodified script has already been compiled and loaded
Info in <ACLiC>: it will be regenerated and reloaded!
Info in <TMacOSXSystem::ACLiC>: creating shared library /Users/rwkelley/temp/.rootbuild//Users/rwkelley/Development/dpm/research/optimization/./cpp/reach_C.so
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/System/Library/Extensions/AMDMTLBronzeDriver.bundle/Contents/MacOS/AMDMTLBronzeDriver' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error in <ACLiC>: Compilation failed!

The other issue I saw in when I have an error in my code and it fails to compile. The steps to reproduce are:

Introduce an intentional error in the source code:

root [2] .x cpp/reach.C++
Info in <ACLiC>: unmodified script has already been compiled and loaded
Info in <ACLiC>: it will be regenerated and reloaded!
Info in <TMacOSXSystem::ACLiC>: creating shared library /Users/rwkelley/temp/.rootbuild//Users/rwkelley/Development/dpm/research/optimization/./cpp/reach_C.so
In file included from input_line_12:9:
././cpp/reach.C:34:5: error: unknown type name 'TTreeReaderXX'
    TTreeReaderXX reader(&e);
    ^
Error in <ACLiC>: Dictionary generation failed!

Fix error and recompile:

root [3] .x cpp/reach.C++
Info in <TMacOSXSystem::ACLiC>: creating shared library /Users/rwkelley/temp/.rootbuild//Users/rwkelley/Development/dpm/research/optimization/./cpp/reach_C.so
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/System/Library/Extensions/AppleIntelHD5000GraphicsMTLDriver.bundle/Contents/MacOS/AppleIntelHD5000GraphicsMTLDriver' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error in <ACLiC>: Compilation failed!

Can someone explain this? I believe these are related issues.

I’ve attached the script and a small ROOT file with the data.
reach.C (3.2 KB)

I’m running on OSX 10.11 with ROOT from homebrew:

[rwkelley@vector optimization]$  brew info root6
homebrew/science/root6: stable 6.08.02 (bottled), HEAD

[rwkelley@vector Dropbox]$  clang --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[rwkelley@vector Dropbox]$  uname -a
Darwin vector.local 15.6.0 Darwin Kernel Version 15.6.0: Mon Jan  9 23:07:29 PST 2017; root:xnu-3248.60.11.2.1~1/RELEASE_X86_64 x86_64

I’ve also tried using version 6.08.04 compiled from source.

Please let me know if you know what is going on?

Thanks,
Ryan

Axel · February 27, 2017, 10:02am

Hi Ryan,

I remember seeing this. We are trying to dig out where we had seen it and whether it’s already fixed or not - give me a couple of hours…

Axel.

Axel · February 27, 2017, 1:51pm

Okay so this is https://sft.its.cern.ch/jira/browse/ROOT-8511 which is not yet fixed :-/

Axel.

rwk7t · February 27, 2017, 11:51pm

Hi,

Thanks for responding. It’s not clear from the link you send that this is the same issue. This issue basically makes the interpreter unusable. Is there any prognosis of it being fixed?

Thanks,
Ryan

Axel · February 28, 2017, 1:05pm

Hi Ryan,

I grabbed the issue and fixed it. That will be part of the upcoming v6.08/06 and the next dev release, scheduled for this week (+/-). But you can of course already build from sources yourself.

Axel.

rwk7t · February 28, 2017, 5:54pm

Awesome!

Pulling from the HEAD got me going. Thank you for the quick response.

-Ryan

rwk7t · March 2, 2017, 1:17am

Opps,

This problem doesn’t seem to be solved yet.

Here is a simple ROOT script to reproduce a similar problem:

#include <random>

void test()
{
    std::random_device rd;
    std::mt19937 gen(rd());
    std::bernoulli_distribution random_bool(0.01);
    std::uniform_int_distribution<int> random_int(0, 10);
}

Now, in the interpreter, again it compiles fine the first time but fails on the second consecutive compilation using ACLiC:

[rwkelley@vector optimization]$  root
root [0] gROOT->GetVersion()
(const char *) "6.09/01"
root [1] .L test.C++
Info in <TMacOSXSystem::ACLiC>: creating shared library /Users/rwkelley/temp/.rootbuild//Users/rwkelley/Development/dpm/research/optimization/./test_C.so
root [2] .L test.C++
Info in <ACLiC>: unmodified script has already been compiled and loaded
Info in <ACLiC>: it will be regenerated and reloaded!
Info in <TMacOSXSystem::ACLiC>: creating shared library /Users/rwkelley/temp/.rootbuild//Users/rwkelley/Development/dpm/research/optimization/./test_C.so
In file included from test_C_ACLiC_dict dictionary payload:10:
././test.C:6:18: error: no matching constructor for initialization of 'std::mt19937' (aka 'mersenne_twister_engine<unsigned int, 32, 624, 397, 31, 2567483615U, 11, 4294967295U, 7, 2636928640U, 15, 4022730752U, 18, 1812433253>')
    std::mt19937 gen(rd());
                 ^   ~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:2056:29: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'result_type' (aka 'unsigned int') to 'const std::__1::mersenne_twister_engine<unsigned int, 32, 624, 397, 31, 2567483615, 11, 4294967295, 7, 2636928640, 15,
      4022730752, 18, 1812433253>' for 1st argument
class _LIBCPP_TYPE_VIS_ONLY mersenne_twister_engine
                            ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:2056:29: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'result_type' (aka 'unsigned int') to 'std::__1::mersenne_twister_engine<unsigned int, 32, 624, 397, 31, 2567483615, 11, 4294967295, 7, 2636928640, 15, 4022730752,
      18, 1812433253>' for 1st argument
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:2114:28: note: candidate template ignored: disabled by 'enable_if' [with _Sseq = unsigned int]
        typename enable_if<__is_seed_sequence<_Sseq, mersenne_twister_engine>::value>::type* = 0)
                           ^
Warning in <TInterpreter::TCling::RegisterModule>: Problems declaring payload for module test_C_ACLiC_dict.

I’m using the HEAD of the repo (as of yesterday). Any thoughts?

Thanks,
Ryan

Axel · March 2, 2017, 5:45pm

Hi Ryan,

Yes, that’s a known problem with cling, we are planning on solving the majority of these reloading problems this year. Sorry, I know how annoying this is…

Cheers, Axel

rwk7t · March 3, 2017, 2:49pm

Hi Axel,

Thanks for the response. This is a critical issue in ACLiC in ROOT6 that I don’t recall from ROOT 5. This essentially makes ACLiC useless at the moment. Any chance of this getting fixed soon? What the timescale?

Thanks,
Ryan

Axel · March 4, 2017, 10:51am

Hi Ryan,

It’s not just with ACLiC. You will likely see the same issue if you load and re-load the script.

I cannot give a detailed time scale, but as I said, I recognize how fundamental this is, and we plan to make progress on that this year. I hope 6.10 end of May will “already” be much improved.

Cheers, Axel

rwk7t · March 5, 2017, 10:27pm

HI Axel,

Thanks for getting back to me. I’ll keep on eye on the changes.

-Ryan