Why doesn't #include <Python.h> work?

Question

I'm trying to run Python modules in C++ using "#include <Python.h>", however, after setting the "Additional Include Dependencies" of the project to "\include" I get the following error when debuging,

LINK : fatal error LNK1104: cannot open file 'python27_d.lib'

I read that I should download the development version of Python, but I didn't find a link for that, plus, don't I just need the file 'python27_d.lib' to be copied to the "libs" folder?

Please note that I'm using the Anaconda distribution of Python.

Thanks in advance!

Honkytonk

What do you mean by "run Python modules in C++"? To do that, you have to embed a Python interpreter. Just doing #include <Python.h> doesn't do that. – Bane

Meanwhile, have you read Building C and C++ Extensions on Windows and Linking Requirements (for embedding)? Are you intending to embed your interpreter statically, or dynamically? Where did you get the interpreter you're trying to embed? – Bane

It's probably easier just to build the Python libs from the Python source code. – Sitka

@Aya, interesting, how do I build the Python libs? – Honkytonk

Start by reading this. – Sitka

Answer 1

I don't know much about python, but the message indicates that python27_d.lib either doesn't exist, or at least doesn't exist where the linker is looking for it.

You already fixed the compiler include issue, now find the python27_d.lib file with Windows Explorer and and add that path to the Additional Library Dependencies path. It's under Configuration -> Linker -> General -> Additional Library Directories.

The "_d" indicates it's a debug library, so you'll want that one for your Debug configuration, and the one without the "_d" (probably) for your release configuration.

Guaiacum

Thanks, so how do I get the debug library? – Honkytonk

Ahh, sorry, thought it was just a VS issue. Looking around it appears that the release (no "_d") version is distributed, but not the "_d". People have found a couple ways to resolve it here: #11312377 – Guaiacum

I tried the solution "#define MS_NO_COREDLL" and it seems to be working thanks a million :), but I don't really understand why – Honkytonk

It appears that python.h explicitly links against debug or release libraries depending on preprocessor directives. I would just leave that to the project config. – Guaiacum

Answer 2

I normally circumvent this by using the non-debug Python lib in debug builds. Typically, this leads to code like:

#ifdef _DEBUG
  #undef _DEBUG
  #include <Python.h>
  #define _DEBUG
#else
  #include <Python.h>
#endif

where you hide the definition of _DEBUG during the inclusion of Python.h.

Treble

DOH! This is the solution! Just make sure your debug version links with python27.lib instead of python27_d.lib. – Beecham

Answer 3

Put visual studio in release mode instead of debug.

Evangelia

It was really this answer combined with the one above that solved my issue. So the steps were: (1) set to release mode, not debug, (2) set the Linker to point to my Python path. – Hoof

Answer 4

You don't necessarily have to use a Python debug build... [even if you are not usimng boost] I would have a look at the boost.python documentation where they have a wrapper for Python.h which handles all the windows debug issues, so that you can build a debug extension against a release python dll.

http://www.boost.org/doc/libs/1_53_0/libs/python/doc/building.html#id19 Python Debugging Builds

Arvy

Answer 5

I ran into similar errors while attempting to use Boost.python to access Anaconda python packages from C++. Let me start off by saying that my personal impression of the C++ Boost libraries is that they are a great idea with incomplete documentation. There is a ton of documentation on boost.org, but it invariably seems to leave out critical details which the authors appear to consider too trivial to bother mentioning. But, let me get off my soapbox ...

The ongoing impetus for me to [hopefully, eventually] figure out how to get Boost.Python to work on my system is that there are so many great Python scientific packages [SymPy, Numpy, SciPy, matplotlib, etc] included in the Anaconda distribution and it would really be great to access them from C++ projects built with Qt Creator. And the Boost docs do seem to suggest that Boost.Python is supposed to do that for me. Alas, those docs seem to leave out critical details that the authors appear to consider too trivial to bother mentioning ...

Anyway, initially, I got a build error indicating that python.h could not be found. I got rid of that by adding these two statements to my Qt Creator project's .pro file, which tell qmake where Boost installed its include files and where Anaconda installed its python.h file on my system:

INCLUDEPATH += C:\boost_1_55_0
INCLUDEPATH += C:\Anaconda\include

After that, I got a LNK1104 error indicating that 'python27.lib' could not be found. I got rid of that by adding these two statements to my .pro file. The first tells qmake where to find Anaconda's python27.lib file. The second tells qmake where to find the boost.python binary:

LIBS += "C:/Anaconda/libs"
LIBS += "C:/boost_1_55_0/stage/lib/libboost_python-vc110-mt-gd-1_55.lib"

But, that is as far as I have gotten so far. I now get an error indicating it cannot open file 'C:/Anaconda/libs.obj' which I have not yet found a fix for. The error, of course, is caused by that file not existing. The challenge is to discover why it is being sought and where to find it.

Deka

Answer 6

On Visual studio, you need to add 'Additional include directories' for the project. Steps below. right click on project -> properties -> c/c++ -> Additional Include Directories -> point it to 'Python\include' folder(ex: c:\python\include).

Authorization