PyROOT import error (PyInit_libPyROOT)

all roottest tests run w/ p3 (was the last thing I did); never used p3 myself, though, so “real life” may have discrepancies

1 Like


all tutorials run with Py3 as well and we have quite many users that take advantage of Py3 and ROOT with the SWAN service. I think it’s ready for prime time (for 6.08 and especially for 6.10).


1 Like

Just to clarify is it possible to have python=ON and python3=ON simultaneously or do we need to have separate builds? If this is true, why does the CMake file not through an error if both are set to on?


it is not yet possible to have Py2 and Py3 simultaneously supported by the same build unfortunately. Thanks for the suggestion! We definitively need to make CMake error out if by chance this is tried by the user.


well, it’s really a limitation of the build and the way the bindings are created.
it’s otherwise perfectly technically possible to achieve this (I am doing it with gopy which generates python bindings to Go packages, allowing to use Go from Py2, Py3, PyPy2, PyPy3 and (possibly, but not tested so presumably broken) IronPython)


What makes this even more confusing (at least to me) is that if python points to python3 and you build it with python=ON and python3=OFF, it will use that default python and build it for Python 3…

I agree with @graipher, the tags are confusing. In addition, I have not yet been able to properly build the python3 bindings. I’ve tried every combination, and I either end up with python2 bindings or nothing at all. I don’t really need the python 3 at the moment, but was trying to ensure that my python 2 was forward compatible.

At least there I was more successful, because I managed to build the Python 3 bindings this way (by accident, though, which is how I discovered this).

Hi All,
While getting the same errors as reported above, installing the latest version (root-6.12.04) on my mac, I’m reading this thread but am not sure what is the solution :frowning:
I have python3 (v3.5.1 installed with homebrew) on my mac and am forcing the root installation with it using -Dpython3=ON.
Here’s the entire installation procedure:

cmake ../root-6.12.04 -DCMAKE_INSTALL_PREFIX=<myprefix> -Dgnuinstall=ON -Dpython3=ON -Droofit=ON
cmake --build .                  ## [ or simply "make -j<N>" on Unix systems ]
cmake --build . --target install ## [ or simply "make install" on Unix systems ]

It seems to install well and I can open root at least.
However, when trying to do something simple with python like:

#!/usr/bin/env python
import os, sys
import math
import ROOT
from ROOT import *

I get this error:

Traceback (most recent call last):
  File "", line 4, in <module>
    import ROOT
  File "my_root_v6.12.04_python_v3/lib/root/", line 24, in <module>
    import cppyy
  File "my_root_v6.12.04_python_v3/lib/root/", line 61, in <module>
    import libPyROOT as _backend
ImportError: dynamic module does not define module export function (PyInit_libPyROOT)

What have I missed :grimacing:?

The python3 flag does not work the way you think it would. You probably have python 2 as the default python?

JIRA 9033

Hi @ksmith,
I confirm it works after manually setting the python executable, headers and library for cmake - please see below if it helps for someone in the future:

base=/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.5 ### only in my case 
cmake ../root-6.12.04 -DCMAKE_INSTALL_PREFIX=${target} -DPYTHON_EXECUTABLE=${base}/bin/python3 -DPYTHON_INCLUDE_DIR=${base}/Headers -DPYTHON_LIBRARY=${base}/lib/libpython3.5m.dylib -Dgnuinstall=ON -Dpython3=ON -Droofit=ON -Dminuit2=ON
cmake --build .
cmake --build . --target install

I now get the ImportError: "from ROOT import *" is not supported in Python 3 error but I think this is a known issue ( Is there a workaround for this backward-incompatibility?


Glad to hear you’ve gotten it sorted.

What do you mean by backward incompatibility? I assume you are attempting to write for both python 2 and 3? In general I do not use the import * option as it clutters the namespace. Adding ROOT. before the classes does not seem overly arduous for me and avoids this issue.

Hi All,

I’m having a similar problem with the newest Root versions 6.18/00 and 6.16/00, but when I use the exact same install procedure in version 6.12.06 it works mostly as expected. Let me describe:

The cmake configuration I use during install from my build directory is just:

cmake ../root-versionNumber/ -Dpython=ON -Dpyroot_experimental=ON -DPYTHON_EXECUTABLE=/usr/bin/python3

Using the compiled 6.12.06, when I try “root --notebook” the Jupyter notebook loads correctly on the local server. But when I use the compiled 6.18 (same thing happens in 6.16 as well) it crashes with this reference to python 2.7:

Traceback (most recent call last):

  File "/usr/local/bin/jupyter-notebook", line 11, in <module>
  File "/usr/local/lib/python2.7/dist-packages/jupyter_core/", line 267, in launch_instance
    return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/traitlets/config/", line 657, in launch_instance
  File "</usr/local/lib/python2.7/dist-packages/decorator.pyc:decorator-gen-7>", line 2, in initialize
  File "/usr/local/lib/python2.7/dist-packages/traitlets/config/", line 87, in catch_config_error
    return method(app, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/notebook/", line 1630, in initialize
  File "/usr/local/lib/python2.7/dist-packages/notebook/", line 1378, in init_webapp
  File "/usr/local/lib/python2.7/dist-packages/notebook/", line 159, in __init__
    default_url, settings_overrides, jinja_env_options)
  File "/usr/local/lib/python2.7/dist-packages/notebook/", line 252, in init_settings
  File "/usr/local/lib/python2.7/dist-packages/traitlets/", line 556, in __get__
    return self.get(obj, cls)
  File "/usr/local/lib/python2.7/dist-packages/traitlets/", line 535, in get
    value = self._validate(obj, dynamic_default())
  File "/usr/local/lib/python2.7/dist-packages/notebook/", line 867, in _default_allow_remote
    for info in socket.getaddrinfo(self.ip, self.port, 0, socket.SOCK_STREAM):
socket.gaierror: [Errno -2] Name or service not known

Has something changed at the CMake configuration stage for Python 3 integration? Or did a bug creep in somewhere?



Hi Mike,
This is not related to the Python version, it is another error.

It has to do with a bug in Jupyter, here you can find more information:

The bug of Jupyter is triggered when including the configuration option c.Notebookapp.ip = '*', which is used by ROOT. You can either move to a newer version of Jupyter or go to $HOME/.rootnb/ and remove the aforementioned option.

1 Like

just want to confirm this error on root 6.18-02, with jupyter 4.4.0, which is the latest on debian-10 if you install through the package manager and not pip. I’ve had trouble with pip in the past so I stick with the repository version of python libraries.

Hi @spacestationspaz ,

Thank you for reporting, according to this ticket:

the issue was visible in Jupyter in version 5.7.0 but not in 5.6.0. Last version is 6.0.1, so that one should be ok.
Anyway, you can use the workaround I explained above about modifying

Hi @etejedor, I fixed the problem with your solution. However, the version of Jupyter I’m using (4.4) is the latest in the debian repositories for Buster. I have to avoid pip because it can cause conflicts with system installed libraries. Thanks.

Glad to hear it works now with the workaround.

And if in the future you move to a newer system with a newer Jupyter, the issue will be already solved.

I am having the same issue, but as I am running PyROOT in Windows, I have just run the executable, and not been able to specify Python versions in CMake.
Do I have to use Python 2 for it to be compatible with PyROOT?

I am using root_v6.18.04 and Python 3.7

File “D:/Documents/”, line 8, in
from ROOT import TCanvas

File “C:\Users\root_v6.18.04\bin\”, line 24, in
import cppyy

File “C:\Users\root_v6.18.04\bin\”, line 61, in
import libPyROOT as _backend

ImportError: DLL load failed: The specified module could not be found.

1 Like

I actually have the same problem right now for Windows. Is there a fix for this?