PyROOT needs ROOT with "--enable-shared"

The thread [url]The version of ROOT and the compatibility with the Python seems to suggest that if one wants to enable PyROOT, one MUST configure ROOT adding explicitly the “–enable-shared” option.
if this is really the case, then one should add an explicit note in and possibly in
Note: the first above page (about PyROOT installation) mentions that you may need to “–enable-shared” just when configuring the old python 2.2, but it says nothing about adding this flag to ROOT.


for ROOT, “enable_shared” being true is the default on non-Windows platforms; it should not be necessary to add it. For the missing symbols that appear missing in the referenced thread, the libraries to link with are -pthread and -lutil (on Linux). I’m not sure why they’re not appearing, as they do for my platform. However, the .so version is definitely recommended, even though the .a should still be usable …


If “.a” should be usable, why is there the explicit requirement for “–enable-shared” when building python 2.2 from source?


first of, the .so is vastly preferred. There are many different ways of getting into trouble when using the .a, especially if other (pre-build) extension modules are used as well, so it’s not recommended, even if it can work. Actually, if you do not intend to use TPython from CINT, there’s no reason to link with any libpython.

The doc you’re referring to is talking about “distribution[s] of Python”. Binary installs, in particular RH which was popular with experiments at the time, carried the .a and .so for p2.3 and later, whereas for p2.2, they only came with the .a, so a build from source was needed. Part of the problem with the doc is that it’s old, though: I don’t think that p2.2 even compiles out-of-the-box with a current gcc, so I doubt anyone cares.

Today, an incredible (to me, anyway) number of applications use python in some form or another. I thus strongly recommend to only use the system python when building ROOT from source and not install other versions in /usr/local, as it is an invitation for trouble. (A location other than /usr/local is easy to handle, though.)