wlav
commented
1 year ago Can't mix these: that old ROOT uses Cling based on Clang3; modern cppyy uses Cling based on Clang9. Both use Cling through libCling.so. Clashes will ensue.
Closed marc1uk closed 1 year ago
wlav
commented
1 year ago Can't mix these: that old ROOT uses Cling based on Clang3; modern cppyy uses Cling based on Clang9. Both use Cling through libCling.so. Clashes will ensue.
marc1uk
commented
1 year ago I see. Is there an old cppyy version that would be compatible?
wlav
commented
1 year ago That release is from March 2017. The first public release of cppyy on PyPI is from July 2017. You probably don't want to go there. You're better off using the old cppyy.py that you had at the beginning (from cppyy.gbl.std import vector doesn't work, but accessing vector = cppyy.gbl.std.vector probably will).
One way or another, both those dates are more than 5 years ago. cppyy has been under non-stop development. The difference in functionality is going to be huge.
marc1uk
commented
1 year ago :pensive: It's great that things keep progressing, but it does make keeping a stable system tough. 2017 may sound like forever ago, but I've been on this experiment since 2015, and at that time ROOT 6 was considered "new". Experiments do typically run over those kinds of timescales, and constantly updating package versions (particularly ones deeply integrated with others like ROOT) is a lot of work. At some point "let's just drop everything and get all the latest stuff" just isn't an option.
Anywho. I guess I'll keep fiddling and see what I can do. Thanks for the quick and definitive reply, it's really helpful. :+1:
wlav
commented
1 year ago But why do you need to have the latest (non-HEP) cppyy in old ROOT? Ie., why do you need to update at all? And if you do need to update, why only update parts of the software and not everything?
Current ROOT has a moderately updated cppyy (2020 or so), and is probably going to suit your needs better.
marc1uk
commented
1 year ago Some newer collaborators want to use machine learning algorithms from python, which of course require all the latest-and-greatest libraries, along with a python bindings that integrate with our existing c++ stuff. I'm not familiar with the python bindings provided by ROOT - I just googled c++/python bindings and found cppyy. If there's a built-in version in ROOT 6.08 that's probably our best option.
wlav
commented
1 year ago Yes! You do not need public cppyy at all in any which way or form. ROOT has PyROOT, which in newer versions is indeed based on cppyy (which itself was originally forked off PyROOT, so the variance in functionality between 2017 PyROOT and 2017 cppyy is going to be minimal; it's mostly cleanup/performance that was done first), but there, too, you won't need public cppyy, as ROOT ships with a builtin copy.
I'm trying to add cppyy into a framework that also uses ROOT. As usual, the mesh of dependencies is a pain, so we're using an old version of ROOT: 6.08.06. I can install cppyy just fine, but once I
source thisroot.shfor my ROOT installation, cppyy fails when trying toimport cppyy.gbl.std vectorAs you mentioned in #77 python is finding the wrong version of cppyy. So I tried disabling the python bindings in ROOT, rebuilding with
--Dpyroot=OFF -Dpython=OFF -Dpython3=OFFbut I now get a segfault onimport cppyy:I can get around this by putting the path to the corresponding cppyy libraries in LD_LIBRARY_PATH first:
export LD_LIBRARY_PATH=/root/.local/lib/python3.8/site-packages/cppyy_backend/lib:/ToolAnalysis/ToolDAQ/root-6.08.06/install/libafter which cppyy works, but now firing up a ROOT shell gives:Granted these are warnings not errors, but I have a sinking feeling that this will cause problems further down the line. It seems I have to choose; ROOT or cppyy. Is it possible for both to play nice? What's the necessary configuration?