Closed marc1uk closed 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.
I see. Is there an old cppyy version that would be compatible?
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.
: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:
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.
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.
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.sh
for my ROOT installation, cppyy fails when trying toimport cppyy.gbl.std vector
As 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=OFF
but 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/lib
after 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?