does any of the libraries show contain libpython3.3.so, libpython.so, libpython3.3.a, or libpython3.3.a? If not, does it exist somewhere else on the system? Also, the choice of lib64 or lib32 should be based on the python executable used.
Note that p3.3 is rarely used with PyROOT. It should work (except for the buffer interface, which I still have to rewrite), but is otherwise little tested.
Also I tried to compile with python 2.7 and I have exactly the same problem
./configure --with-python-incdir=/usr/include/python2.7 --with-python-libdir=/usr/lib/ --enable-python
For python2.7 setup, make sure that which python refers to p2.7 for that to work, even with incdir and libdir set (python is used to pre-compile .py files).
which symlink and combination of flags to the configure script did you create? From the looks of it, this is a build against the p2 headers, and a link against the p3 library.
the configure script output:
Checking for Python.h … /usr/include/python3.3m/
Checking for python3.3, libpython3.3, libpython, python, or Python … /usr/lib64/
but why this: /usr/lib64/libpython3.3.so -> /usr/lib/libpython3.3m.soas arguable the symlink in lib64 should point to the lib64 version rather than the lib32 version as has been done here, no?
The thing is that I only have installed the 64bit version (pretty sure), in this system /usr/lib and /usr/lib64 are the same, actually there is another folder called /usr/lib32 which doesn’t have any python library. In any case I changed what you suggested but I got the same error…
well … beats me then. Remains that the missing PyString… etc. (which are gone from p3.x) I can only explain if there’s a mix of p2.x and p3.x happening, but I’m not seeing where else there could be a mash-up.
git clone http://root.cern.ch/git/root.git #if needed
cd root
git tag -l
git checkout -b v5-34-08 v5-34-08 #switch branch/tag
I always rather clean/distclean everything and then configure and compile the code
make clean
make distclean
./configure --enable-{minuit2,unuran,table,roofit,table,gdml} --with-python-incdir='/usr/include/python2.7' --with-python-libdir='/usr/lib/python2.7/'
make
After the compilation, create back the default python system symlink
cd /usr/bin
sudo rm python
sudo ln -s python3 python
In new terminal you may try, e.g.,:
source /opt/rootgit/root/bin/thisroot.sh
alias ipython=ipython2
alias python=python2
echo ROOT version: `python -c 'import ROOT; print ROOT.gROOT.GetVersion()'`
should give you “ROOT version: 5.34/08” (if not then something went wrong … ).
Hello Folks
I just recently installed ROOT with pyROOT support under Archlinux. I had some trouble with it and I like to share my experience.
It seems to me, that problems occure because Arch is by default using python 3.4 and pyROOT (ROOT version: 6.02/01) doesn’t seem to be fit for this at the moment. Please correct me if I’m wrong.
Jiri’s post did help a lot, but it was not successful for me.
Instead of
I had to create a link for the inclue and lib folder, so I did:
cd /usr/bin
sudo rm python
sudo ln -s python2.7 python
cd /usr/include
(rm was not needed)
sudo ln -s python2.7 python
cd /usr/lib/
(rm was not needed)
sudo ln -s python2.7 python
afterwards I was able to build root with pyROOT support via:
cd to rootfolder, for me:
make clean
make distclean
./configure linuxx8664gcc --enable-python
make -j5
To check if build process was sucessfull, see if libPyROOT.so exists:
Also dont forget to set environment varables. If one wants to use pyROOT. Aditionally PYTHONPATH must be set. I use in my ~/.bashrc
Crucial is the part --with-python-libdir={}. Without the two paths it won’t work (and that’s the reason I’m posting this!). I am running Arch Linux with python2.7 (and python3.5 as default link from /usr/bin/python).
Running this with python3.5 fails cause of undefined references of sth like ‘PyString_FromString’. Couldn’t figure out what’s wrong there.
The solution of swen without creating and delating the symlinks is, of course, better (I had a problem to find correct options for the ./configure).
Another solution how to install arbitrary ROOT version is to use conda - create an enviroment with a python version of your choice, activate it (which should pick up the correct python version) and compile/install ROOT from source as usual. This works for me (similar approach with pip did not work for me).
Have not tried myself but you may try to install ROOT 5 or 6 + python 2 or 3 as a already existing conda package (and rootpy if you want) : github.com/rootpy/rootpy/issues/642
The conda approach allows separation of a developement enviroment from the system one and more control over the versions of packages in the enviroment. It should be also much more portable solution.
).