Static linking Python library to C (C++) with Numpy

Question

I'm developing a C++ library, which has python embedded. What I would like to do is to statically link Python library, so that there won't be configuration issues, when I switch to production server. So far, I'm able to link libpython3.5m.a statically (I had to build Python from sources though, because it seems, that packaged libraries aren't compiled with -fPIC flag). However, I came to a problem, that it seems, there's no Numpy: When I run application, which uses my library, it prompts me with an error:

ImportError: numpy.core.multiarray failed to import

And this error is caused by import_array1() macro, that (AFAIK) is used to import the numpy routines to C++. I tried linking libnpymath.a as well as libnpysort.a , which I found in numpy build dir, but to no avail. Do you happen to know, if such static linking is possible and how to do it? I guess it should be possible, since numpy is written in C...

Answer 1

What I would like to do is to statically link Python library, so that there won't be configuration issues, when I switch to production server.

This would only be the Python core, it would exclude all of the Python libraries. You still need to ship all of the Python code.

...since numpy is written in C...

This is incorrect. NumPy is written about half in C and half in Python. It looks like the C part is the part that's not loading here, since numpy.core.multiarray is written in C, and you wouldn't normally import that yourself, it would normally be imported by the Python part of NumPy.

Linking in the C code is not enough anyway, you need to load initialize the associated Python modules exported by the C code. Without static linking, Python would just find the multiarray.so file in the right place and load it. When you build Python statically, you would would normally edit the Modules/Setup.local file with the modules you want statically compiled into Python. However, this is not designed to work with arbitrary third-party modules like NumPy. See: Compile the Python interpreter statically?

---

Honestly, if you are just trying to make sure that the same version of Python runs on both development and production systems, there are vastly easier ways to do this, like virtualenv. CPython is simply not designed to be statically linked.