Missing Python.h while trying to compile a C extension module - c++

I'm following this tutorial on how to extend Python with C\C++ code.
The section named "Building the extension module with GCC for Microsoft Windows" fails for me with the following error:
fatal error: Python.h: No such file or directory
The section named "Building the extension module using Microsoft Visual C++" also fails with a similar error:
fatal error C1083: Cannot open include file: 'Python.h': No such file or directory
What should I do to solve this?

For Linux, Ubuntu users to resolve the issue of missing Python.h while compiling, simply run the following command in your terminal to install the development package of python:
In Terminal: sudo apt-get install python-dev
Good luck

Do you have the python dev files so that you can find Python.h?
Do you have the location of Python.h specified to your compiler? with gcc this is usually done through a -I path to include.
Figuring out which of those is failing will solve your problem.
from the article you linked:
gcc -c hellomodule.c -I/PythonXY/include
gcc -shared hellomodule.o -L/PythonXY/libs -lpythonXY -o hello.dll
They assumed you installed python in the default location c:\pythonXY(Where X is the major version number and Y is the minor version number).(in your case Python26) If you put python somewhere else replace /PythonXY with where ever you installed it.

The Python official documentation has already made it clear. Check it out here
The header files are typically installed with Python. On Unix, these are located in the directories prefix/include/pythonversion/ and exec_prefix/include/pythonversion/, where prefix and exec_prefix are defined by the corresponding parameters to Python’s configure script and version is '%d.%d' % sys.version_info[:2]. On Windows, the headers are installed in prefix/include, where prefix is the installation directory specified to the installer.
To include the headers, place both directories (if different) on your compiler’s search path for includes. Do not place the parent directories on the search path and then use #include ; this will break on multi-platform builds since the platform independent headers under prefix include the platform specific headers from exec_prefix.
And they have provided a convenient way to get the correct cflags that we should pass to compiler. here
So for example, here is what I got after running the command
root#36fd2072c90a:/# /usr/bin/python3-config --cflags
-I/usr/include/python3.5m -I/usr/include/python3.5m -Wno-unused-result -Wsign-compare -g -fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Pass those flags to the compiler, and it will work.

Related

--with-sysroot is not honored during a compile on OS X?

I have a C++ project. I am testing a cross-compile with Autotools on OS X for iOS. I configure with:
$ echo $IOS_SYSROOT
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk
$ CXXFLAGS="-DNDEBUG -g2 -O3 -arch arm64" ./configure --with-sysroot="$IOS_SYSROOT" --build=`config.guess` --host=aarch64-ios
When make'ing it results in (line breaks added for clarity):
libtool: compile: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-DHAVE_CONFIG_H -I. ... -DNDEBUG -g2 -O3 -arch arm64 -MT adhoc.lo -MD -MP -MF .deps/adhoc.Tpo -c adhoc.cpp -o adhoc.o
In file included from adhoc.cpp:2:
In file included from /usr/include/c++/4.2.1/iosfwd:44:
In file included from /usr/include/c++/4.2.1/bits/c++config.h:41:
In file included from /usr/include/c++/4.2.1/bits/os_defines.h:61:
In file included from /usr/include/unistd.h:71:
In file included from /usr/include/_types.h:27:
In file included from /usr/include/sys/_types.h:32:
/usr/include/sys/cdefs.h:658:2: error: Unsupported architecture
#error Unsupported architecture
...
Notice the wrong header files are being used. The build system's headers are used rather than the iPhone headers. I'm fairly certain --with-sysroot is not being honored. Searching for the keywords seems to indicate its a widespread problem with Autoconf (based on all the bug reports trying to use the feature).
Manually adding CXXFLAGS="-sysroot=$IOS_SYSROOT -arch arm64 ... seems to fix the issue. This seems to be the same problem (or nearly the same problem) detailed at Bug 79885: --with-build-sysroot= does not get honored throughout the build.
There does not seem to be a AC_SYSROOT (or similar) to copy --with-sysroot into AM_CXXFLAGS. Searching the Autoconf site for the keywords is not returning useful hits: "--with-sysroot" site:https://www.gnu.org/software/autoconf/manual.
How are we supposed to handle Autoconf's --with-sysroot option? What is the practice packagers are supposed to follow?
Here are the Autoconf prject files: cryptopp-autotools. There are two files of interest, and they are configure.ac and Makefile.am. I'm not sure what applies to this problem at the moment.
Here's the message where Autoconf tells users to use it:
$ ./configure --help | grep sysroot
--with-sysroot[=DIR] Search for dependent libraries within DIR (or the
compiler's sysroot if not specified).
I'd prefer to supress the message if Autoconf cannot wire-in --with-sysroot properly. Otherwise, users are going to be filling bug reports against us.

C++ header files are not being found

Context: I am building some code for an embedded board. It calls for installing the Xilinx tools, the Linaro toolchain and then invoking a setup bash script in the development board build directory (let's call it setup.sh).
If I do not run setup.sh , I can then build one of the lower level libraries, which has it's own configure script (./configure) which calls the usual ./bootstrap script. In this scenario ./bootstrap , g++ in this case says it can find sstream (the C++ stream header). Ok. Fine.
When I run the setup.sh script (at the top level), g++ then says it CANNOT find sstream. So somehow the g++ environment is changed somehow, and it is this I am trying to figure out.
The output in this erroneous case is
g++ has streams in std:: namespace
g++ does not have sstream
g++ does not have strstream.h
g++ does not have strstrea.h
I am trying to debug this to find out what g++ thinks it is doing and why it cannot find the sstream header. What are some ways to look at what the g++ include and libstdc++ library paths are set to? What environment variables control the behavior of gcc/g++?
#
If I remember correctly, Xilinx ships their own gcc toolchain with their products.
Just add the -I compile file to point to the proper includes path.
Try to search for the header files inside Xilinx's /opt path, so you don't have a mismatch between the header version and the library version.
Makefile's usual env variables are:
# C Compiler: GNU C Compiler
CC = gcc
# Linker: GNU Linker
LD = ld
# C++ Compiler: GNU C++ Compiler
CPP = g++
Also check
CFLAGS
CPPFLAGS
LDFLAGS
Check if $CC is set after you execute setup.sh.

Missing jpeglib.h when building pygame in Cygwin

I'm trying to install pygame with cygwin with the step by step below
http://msdl.cs.mcgill.ca/people/tfeng/svmsccdoc/node49.html
Things are going fine until the last part when I'm running theses 3 lines
export LIBRARY_PATH=/usr/local/lib:$LIBRARY_PATH
export CPATH=/usr/local/include/SDL:$CPATH
python setup.py install build
I have this issue
gcc -fno-strict-aliasing -ggdb -O2 -pipe -Wimplicit-function-declaration - fdebug-prefix-map=/usr/src/ports/python/python-2.7.8-1.i686/build=/usr/src/debug/python-2.7.8-1 -fdebug-prefix-map=/usr/src/ports/python/python-2.7.8-1.i686/src/Python-2.7.8=/usr/src/debug/python-2.7.8-1 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/NEED_INC_PATH_FIX -I/usr/include/python2.7 -c src/imageext.c -o build/temp.cygwin-1.7.33-i686-2.7/src/imageext.o
src/imageext.c:35:21: erreur fatale: jpeglib.h : No such file or directory
#include <jpeglib.h>
As you can see, the file jpeglib.h is missing
I tried to install the missing file by downloading the lib
apt-cyg install libjpeg62
But to no avail
Does anyone have seen that issue before? I browsed the net but found nothing relevant.
TIA
libjpeg62 doesn't have jpeglib.h. You need libjpeg-devel instead.
You can search for specific files in packages using the package search function on the Cygwin website.
You can download an already compiled version of PyGame and skip these steps. This can be painful sometimes.
Just check this page : http://www.lfd.uci.edu/~gohlke/pythonlibs/
or
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame , to get directly to PyGame section.
The Python extension unofficial windows binaries. You can find alot of Python libraries on this page.
Using theses packages will make you save a lot of time.

why self built g++ compiler fails to compile my code

I wanted to use latest g++ compiler(4.9.1) on suse linux, but suse only supports an older g++ version. So, I took a latest source code from one of the gnu mirror sites and compiled it myself. Everything went fine. But when I tried to compile my test code using the built g++, the compilation fails with error,
"/root/home/include/c++/4.9.1/x86_64-unknown-linux-gnu/bits/os_defines.h:39:22: fatal error: features.h: No such file or directory".
I can find a "features.h" in "/root/home/include/c++/4.9.1/parallel", but I feel that it should be there in "/root/home/include/c++/4.9.1/" itself.
I copied "/root/home/include/c++/4.9.1/parallel/features.h" to "/root/home/include/c++/4.9.1/" just to see what happens. Now it complains with error "whcar.h" not found.
Have I missed something.
Here are the steps I followed to build g++.
1. /root/home/gcc_build/objdir# ../gcc-4.9.1/configure --prefix=/root/home/ --disable-multilib
2. /root/home/gcc_build/objdir# make -j16
3. /root/home/gcc_build/objdir# make install
4. /root/home/gcc_build/test# /root/home/bin/g++ --sysroot /root/home -m64 test.cpp
I resolved the issue by removing sysroot option and pointing c++ include and library path to my home directory. One thing I noticed was that the g++ source does not come with libc and c header files, and libc has to be installed seperately. But with sysroot option, g++ was trying to look all the header files in my home directory.
Below is the command I used to successfully compile the code.
/root/home/bin/g++ -I /root/home/include/c++/4.9.1 -L /root/home/lib64 -Wl,--rpath=/root/home/lib64 --std=c++0x -m64 test.cpp
Take a look at the GCC Directory Options. It is important to use the correct "specifier" as well (-isystem, -L, -B, -I etc)

QT5 attaching project name with every sourcefile name, compiling error

i want to get started with QT. I donwloaded QT5 MINGW compiler with QT creator and i am trying to build the pre attached example named affine the problem is that the QT5 i think embed the project name with each of source file and thus gives error that file not found. some thing similar
:-1: error: ..affinemain.cpp: No such file or directory
while the file name is just
main.cpp
i don't know how to fix it. I searched lot on internet but could not found anything useful.
I even try to compile from command prompt but i am not fimmiliar with command prompt compiling as i am new to QT and previously i am totally developed with IDE in visual studio and eclipse for java so i have no idea about the make file and compiler command line arguments.
could some body please help me to fix this issue and can you tell please why compiler attaching project name with the source file name?
Thanks in advance
I have got the same problem and my solution may help you.
I am working with Qt5.0.1 now, and there are two distributions to work on windows with it: Qt5.0.1-mingw and Qt5.0.1-msvc2010.
I had to use mingw and there was a problem on my setup that "/" is ignored in path's.
So according to Qt Creator, compiler was called to process file mainwindow.cpp and this file was passed to it
g++ /*truncated*/ ..\qt-example\mainwindow.cpp
Below is the full compiler input:
g++ -c -pipe -fno-keep-inline-dllexport -g -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -DQT_NEEDS_QMAIN -I..\qt-example -I"..\..\..\..\..\..\Qt\Qt5.0.1\5.0.1\mingw47_32\include" -I"..\..\..\..\..\..\Qt\Qt5.0.1\5.0.1\mingw47_32\include\QtWidgets" -I"..\..\..\..\..\..\Qt\Qt5.0.1\5.0.1\mingw47_32\include\QtGui" -I"..\..\..\..\..\..\Qt\Qt5.0.1\5.0.1\mingw47_32\include\QtCore" -I"debug" -I"." -I"." -I"..\..\..\..\..\..\Qt\Qt5.0.1\5.0.1\mingw47_32\mkspecs\win32-g++" -o debug\mainwindow.o ..\qt-example\mainwindow.cpp
And the error produced.
g++.exe: error: ..qt-examplemainwindow.cpp: No such file or directory
g++.exe: fatal error: no input files
compilation terminated.
So, we can see that "\" is ignored by the compiler and file name is merged with directory name.
The solution to that problem goes to the tools that are used - MinGW (Minimalist ports of GCC and Binutils). And also MSYS - a collection of GNU utilities such as bash, make, gawk and grep to allow building of applications and programs which depend on traditionally UNIX tools to be present. In our case - g++.
MSYS is not shipped with Qt5.0.1-mingw and g++ is not using it, but having MSYS available in your PATH environment variable breaks the system.
MSYS is used for git scm, which I have installed, so my path contains links to MSYS that goes bundled with git. So I have next paths in my PATH environment variable.
C:\Program Files (x86)\git\bin;C:\Program Files (x86)\git\cmd
I have not found how MSYS is used by Qt Creator or g++, or where it is linked, but when I have dropped next path from PATH:
C:\Program Files (x86)\git\bin;
and restarted Qt Creator - g++ succeeded on compiling my file, it worked.
The question why/how it influences the Qt Creator/g++ that should not use MSYS utils installed with git is still open.
i can´t comment.
important : delete all the files in the release and debug folder (compiled version) before try the tips of the autor ...