I have the following problem,
I'm building a python module using swig to wrap C-code.
I have installed python, gcc(45),.. using MacPorts.
Here's a minimal setup which reproduces the problem:
Two files:
test.i:
%module test
double sum(double a, double b);
test.c:
double sum(double a, double b){return a+b;}
I run
$ swig -python -I. test.i
$ gcc -fPIC -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c test_wrap.c
$ gcc -c -o test.o test.c
$ gcc -shared -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -lpython -dynamiclib -fPIC -o _test.so test.o test_wrap.o
When I run python (the MacPorts one: /opt/local/bin/python2.7) and try to import the module via import test, the code crashes with exactly the same problem as above.
Examining the file _test.so with otool yields the following:
$ otool -L _test.so
_test.so:
_test.so (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.2)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0)
/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
I found out that in the swig-generated file test.py the line #include <Python.h> is contained. However there is a Python.h in /System/Library/... and one in /opt/local/...
My guess is that the mistake is happening here. But how can I make the compiler/linker point to the correct one?
Thanks a lot for any help!!
Thomas
I don't have a mac, but I have good results by using distutils to deal with multiple Python versions on Linux and Windows when using swig (swig doc and distutil doc). The following shows a minimal example of a setup.py:
from distutils.core import setup,Extension
ext = Extension('_test',sources=['test.c,test.i'])
setup(name='test',ext_modules=[ext],py_modules=["test"])
Distutils is binding to the calling python version and knows about swig. However, it is important to compile by:
python setup.py build_ext
python setup.py build_py
And not calling build directly.
Related
Update
I'm not going to add this as an answer, since I still haven't technically solved the problem. But since I've now spent 2.5 days trying to get things to work with boost-python3, I've lost the will to live with it.
I've just come across pybind11 (how my previous lengthy searches for python binding tools didn't turn it up, I don't know) and am using that. 2.5 days of misery compares to <20 minutes installing and building their cmake example... and all the specific-python-version-dependency-hell is gone.
It's syntactically similar to boost-python but much easier to manage, quicker, is header-only and is more feature rich.
Yay!
Original question
I'm using boost::python to bind a class in python 3.7.2.
The class import successfully but instantiating it gives the following error:
<my-terminal>$ python
Python 3.7.2 (default, Feb 14 2019, 17:36:47)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import classes
>>> t = classes.World()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __init__() should return None, not 'NoneType'
>>>
Here is classes.cpp:
#include <boost/python.hpp>
#include <boost/python/list.hpp>
#include <boost/python/extract.hpp>
#include <string>
#include <sstream>
#include <vector>
struct World
{
void set(std::string msg) { mMsg = msg; }
void many(boost::python::list msgs) {
long l = len(msgs);
std::stringstream ss;
for (long i = 0; i<l; ++i) {
if (i>0) ss << ", ";
std::string s = boost::python::extract<std::string>(msgs[i]);
ss << s;
}
mMsg = ss.str();
}
std::string greet() { return mMsg; }
std::string mMsg;
};
using namespace boost::python;
BOOST_PYTHON_MODULE(classes)
{
class_<World>("World")
.def("greet", &World::greet)
.def("set", &World::set)
.def("many", &World::many)
;
};
Hypothesis
This question, almost identical was solved because of a python 2/3 issue (linking against python 3 instead of python 2 libraries). So I suspected a library linking issue.
Checking the hypothesis
I can't get bjam to work, and wouldn't be able to switch all our build systems over for one module anyway... so am building with cmake, which compiles successfully to classes.so with output as follows, suggesting I'm finding all the correct includes, libraries and executables:
-- Found PythonInterp: /Users/me/.pyenv/versions/boost37/bin/python3 (found suitable version "3.7.2", minimum required is "3")
PYTHON_VERSION_SUFFIX
-- Boost version: 1.68.0
-- Found the following Boost libraries:
-- python37
-- Found PythonLibs: /usr/local/Frameworks/Python.framework/Versions/3.7/lib/libpython3.7m.dylib (found suitable version "3.7.2", minimum required is "3")
-- PYTHON_LIBRARIES = /usr/local/Frameworks/Python.framework/Versions/3.7/lib/libpython3.7m.dylib
-- PYTHON_EXECUTABLE = /Users/thc29/.pyenv/versions/boost37/bin/python3
-- PYTHON_INCLUDE_DIRS = /usr/local/Frameworks/Python.framework/Versions/3.7/include/python3.7m
-- Boost_LIBRARIES = /usr/local/lib/libboost_python37-mt.dylib
Boost-python3 library directory contents:
ls /usr/local/Cellar/boost-python3/1.68.0/lib
libboost_numpy37-mt.a libboost_numpy37.dylib libboost_python37.a
libboost_numpy37-mt.dylib libboost_python37-mt.a libboost_python37.dylib
libboost_numpy37.a libboost_python37-mt.dylib
I used brew install boost, and brew install boost-python3 --build-from-source with my python 3.7 virtualenv activated, to ensure boost-python3 is linked against the correct version of python.
Checking libraries...
otool -L classes.so gives:
classes.so:
/usr/l/opt/boost-python3/lib/libboost_python37-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/Python (compatibility version 3.7.0, current version 3.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
otool -L /usr/local/opt/boost-python3/lib/libboost_python37-mt.dylib gives:
/usr/local/opt/boost-python3/lib/libboost_python37-mt.dylib:
/usr/local/opt/boost-python3/lib/libboost_python37-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
In the related question, that showed their problem. But here it appears fine!
No progress yet...
After the painful process of getting this all compiling properly and checking the linking, I can't spot any flaws. Is this a different problem? Or is there a linking issue that I haven't spotted?
Thanks for any help!
Adding an answer here for those using the Anaconda or Conda-Forge Distribution:
The python interpreter statically links in the libpythonXY library. Which is why it makes the python binary different compared to other distributions.
The fix for the problem reported by OP is to use:
-undefined dynamic_lookup
Instead of:
-lpythonXY
You are creating a Python C/C++ extension, and not embedding the python interpreter. So you shouldn't be linking to the python library. Pybind11 handles this correctly.
See the following for more information:
https://gitlab.kitware.com/cmake/cmake/issues/18100
https://github.com/ContinuumIO/anaconda-issues/issues/9078
One a side note, python 3.8 has added an additional flag: --embed and only then it adds -lpythonXY in the output:
$ python3.8-config --libs
-ldl -framework CoreFoundation
$ python3.8-config --libs --embed
-lpython3.8 -ldl -framework CoreFoundation
I am following a similar example and I adopt the Makefile from here. I have installed python 3.7.4 and boost-python via brew on macOS. To fix the NoneType issue, I follow the procedure below:
1. Check the Python Path
To check the python path, use
which python
If the output does not look like the following one (brew's python installation path)
/usr/local/opt/python/libexec/bin/python
set the PATH variable as
export PATH="/usr/local/opt/python/libexec/bin:$PATH"
Check if the Python path looks like the one above again.
2. Check the Compilation Flag
Below is the adopted Makefile. Note the LIB variable. If the boost-python flag is -lboost_python, change it to -lboost_python37.
CPP = clang++
PYLIBPATH = $(shell python-config --exec-prefix)/lib
# LIB = -L$(PYLIBPATH) $(shell python-config --libs) -lboost_python
LIB = -L$(PYLIBPATH) $(shell python-config --libs) -lboost_python37
OPTS = $(shell python-config --include) -O2
default: hello.so
hello.so: hello.o
$(CPP) $(LIB) -Wl,-rpath,$(PYLIBPATH) -shared $< -o $#
hello.o: hello.cpp Makefile
$(CPP) $(OPTS) -c $< -o $#
clean:
rm -rf *.so *.o
.PHONY: default clean
Recompile the C++ code and run the python script. The NoneType issue should disappear.
Hope this helps.
Note
If you are using anaconda and want to restore the PATH variable after the above changes, try
export PATH="~/anaconda3/bin:$PATH"
Your anaconda's path may be different.
Credit
1. George's comment in How do I use brew installed Python as the default Python?
2. leiyc's comment in ld: library not found for -lboost_python on MacOS
Following up on Nehal's answer for Anaconda based builds. Rereading the FindPython documentation for cmake shows the Python::Module target was added in cmake 3.15 for creating modules. That means the CMakeLists.txt should be:
set(Python3_FIND_VIRTUALENV FIRST)
find_package(Python3 REQUIRED Development)
find_package(Boost REQUIRED python3)
add_library(classes MODULE classes.cpp)
target_link_libraries(classes PRIVATE Python3::Module Boost::python3)
Apparently, the Python3::Python is for embedding Python in another application.
I'm currently unable to using the Cython embedding feature. The binary compiles fine and otool -L embedded returns the following results.
embedded:
#rpath/libpython3.6m.dylib (compatibility version 3.6.0, current version 3.6.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.8.0)
This is the command I ran. Any thoughts on why this is not working? Cython using setup.py works fine when I want to create a Cython module, i.e. I'm able to import the Cython module in Python.
$ make
gcc -c embedded.c -I/Users/$USER/miniconda3/include/python3.6m -I/Users/$USER/miniconda3/include/python3.6m
gcc -o embedded embedded.o -L/Users/$USER/miniconda3/lib -L/Users/$USER/miniconda3/lib/python3.6/config-3.6m-darwin -lpython3.6m -ldl -framework CoreFoundation -Wl,-stack_size,1000000 -framework CoreFoundation
$ ./embedded
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'
Current thread 0x000000010f8113c0 (most recent call first):
[1] 32931 abort ./embedded
Suggestions?
You are basically trying to run a Python native code extension as a stand alone binary without the Python interpreter. This will never work.
Cython extension code produces extensions to the Python interpreter.
They are shared modules that can only be loaded within a running Python interpreter. They cannot be used as stand alone binaries.
If you want to make and distribute a stand alone binary of Python code with or without extensions, the interpreter will need to be bundled along with the code - see cx_freeze.
Recently, I am learning boost C++ library. I want to use python to call exist C++ project. I have install boost under OSX 10.11 using brew install boost. My python version 2.7.
I make a hello.c:
char const* greet()
{
return "hello, world";
}
#include <boost/python.hpp>
BOOST_PYTHON_MODULE(hello)
{
using namespace boost::python;
def("greet", greet);
}
and Makefile:
PYTHON_VERSION = 2.7
PYTHON_INCLUDE = /usr/include/python$(PYTHON_VERSION)
# location of the Boost Python include files and library
#
BOOST_INC = /usr/local/include
BOOST_LIB = /usr/local/lib
#
# compile mesh classes
TARGET = hello
$(TARGET).so: $(TARGET).o
g++ -shared -Wl $(TARGET).o -L$(BOOST_LIB) -lboost_python -L/usr/lib/python$(PYTHON_VERSION)/config -lpython$(PYTHON_VERSION) -o $(TARGET).so
$(TARGET).o: $(TARGET).c
g++ -I$(PYTHON_INCLUDE) -I$(BOOST_INC) -fPIC -c $(TARGET).c
However, after I run make and got hello.so. I met following error when I run python code:
import hello
print hello.greet()
error:
Traceback (most recent call last):
File "test.py", line 4, in <module>
import hello
ImportError: dlopen(/Users/einverne/boost_test/hello.so, 2): Library not loaded: libboost_python.dylib
Referenced from: /Users/einverne/boost_test/hello.so
Reason: unsafe use of relative rpath libboost_python.dylib in /Users/einverne/boost_test/hello.so with restricted binary
Take this link as a reference.
To my problem, use otool -L hello.so:
hello.so:
hello.so (compatibility version 0.0.0, current version 0.0.0)
libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.10)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
you can see that libboost_python.dylib is not point to the really exist path.
so use this command:
install_name_tool -change libboost_python.dylib /usr/local/lib/libboost_python.dylib hello.so
and run otool -L hello.so again:
hello.so:
hello.so (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.10)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
and finally run python test.py, I get the result.
It is advisable to change the Boost dynamic libraries themselves on MacOS instead of changing the executables or other dynamic libraries linked against them. Run the bash script given below in the directory that contains your libboost_XXX.dylib libraries:
#!/bin/bash
# Modify the absolute dylib paths baked into the libraries
for i in *.dylib
do
FULLPATH=`pwd`/$i
install_name_tool -id $FULLPATH $i
echo -change $i $FULLPATH
done > changes
for i in *.dylib
do
install_name_tool `cat changes` $i
done
rm changes
You will need to do this only once after you built the Boost libraries. No mucking around with the executables linking against them is needed.
I'm experiencing a problem with matplotlib, to be more precise with pyplot.
Just after installing, doing
import matplotlib.pyplot
gives me this error:
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so, 2): Symbol not found: _png_create_info_struct
Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so
Expected in: flat namespace
in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so
So I have no idea what is going on. I'm on Mac OS X 10.6, I have installed python2.7 from disk image and matplotlib from the terminal by using the tar.gz and doing the usual
python setup.py build
python setup.py install
When the installation starts I see:
BUILDING MATPLOTLIB
matplotlib: 1.1.0
python: 2.7 (r27:82508, Jul 3 2010, 21:12:11) [GCC 4.0.1
(Apple Inc. build 5493)]
platform: darwin
REQUIRED DEPENDENCIES
numpy: 1.6.1
freetype2: 10.0.4
OPTIONAL BACKEND DEPENDENCIES
libpng: 1.2.44
Tkinter: no
* TKAgg requires Tkinter
Gtk+: no
* Building for Gtk+ requires pygtk; you must be able
* to "import gtk" in your build/install environment
Mac OS X native: yes
Qt: no
Qt4: no
Cairo: no
OPTIONAL DATE/TIMEZONE DEPENDENCIES
datetime: present, version unknown
dateutil: matplotlib will provide
pytz: matplotlib will provide
adding pytz
OPTIONAL USETEX DEPENDENCIES
dvipng: 1.13
ghostscript: 8.61
latex: 3.1415926
Any help guys please!
Cheers
http://fonnesbeck.github.io/ScipySuperpack/
I've been fighting this same problem and the answer was to install the ScipySuperpack. The problem (at least for me) was that I have a 64 bit version of Python, and the version of matplotlib I was pulling from github was 32 bit. I cloned the ScipySuperpack repository and ran the setup script and it worked.
No amount of fighting with brew or ports was getting me anywhere.
In case anyone has the same problem as me and finds this thread, here is how I solved it.
First, I follow the current matplotlib README.osx, along with this guy's advice (not sure if that's necessary)...
brew install freetype --universal
brew install libpng --universal
export CPPFLAGS="-I/usr/local/opt/libpng/include -I/usr/local/opt/freetype/include"
export LDFLAGS=" -L/usr/local/opt/libpng/lib -L/usr/local/opt/freetype/lib"
I also set those variables as recommended by brew.
Then, I did the following
(running from matplotlib build directory, after having built and installed)
drigz#mbp matplotlib 0$ find . -name _png.so
./build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
drigz#mbp matplotlib 0$ otool -L ./build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
./build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so:
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 830.0.0)
No libpng! A bad sign... let's see the build output again...
drigz#mbp matplotlib 0$ rm ./build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
drigz#mbp matplotlib 0$ python setup.py build
[SNIP]
c++ -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -isysroot /Developer/SDKs/MacOSX10.6.sdk -g -L/usr/local/opt/libpng/lib -L/usr/local/opt/freetype/lib -I/usr/local/opt/libpng/include -I/usr/local/opt/freetype/include build/temp.macosx-10.6-intel-2.7/src/_png.o build/temp.macosx-10.6-intel-2.7/src/mplutils.o build/temp.macosx-10.6-intel-2.7/CXX/cxx_extensions.o build/temp.macosx-10.6-intel-2.7/CXX/cxxsupport.o build/temp.macosx-10.6-intel-2.7/CXX/IndirectPythonInterface.o build/temp.macosx-10.6-intel-2.7/CXX/cxxextensions.o -L/sw/lib -L/usr/local/lib -L/usr/lib -L/usr/X11/lib -lpng14 -lz -lstdc++ -lm -o build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
ld: warning: in /sw/lib/libpng14.dylib, file was built for i386 which is not the architecture being linked (x86_64)
It's not using the right libpng: what does brew provide?
drigz#mbp matplotlib 0$ echo $LDFLAGS
-L/usr/local/opt/libpng/lib -L/usr/local/opt/freetype/lib
drigz#mbp matplotlib 0$ ls /usr/local/opt/libpng/lib
libpng.a libpng.la libpng15.a pkgconfig
libpng.dylib libpng15.15.dylib libpng15.dylib
Let's try to fix that by copy-pasting the command but changing -lpng14 to -lpng15... (there's probably a better way to stop it from using the wrong one, but this worked)
drigz#mbp matplotlib 0$ c++ -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -isysroot /Developer/SDKs/MacOSX10.6.sdk -g -L/usr/local/opt/libpng/lib -L/usr/local/opt/freetype/lib -I/usr/local/opt/libpng/include -I/usr/local/opt/freetype/include build/temp.macosx-10.6-intel-2.7/src/_png.o build/temp.macosx-10.6-intel-2.7/src/mplutils.o build/temp.macosx-10.6-intel-2.7/CXX/cxx_extensions.o build/temp.macosx-10.6-intel-2.7/CXX/cxxsupport.o build/temp.macosx-10.6-intel-2.7/CXX/IndirectPythonInterface.o build/temp.macosx-10.6-intel-2.7/CXX/cxxextensions.o -L/sw/lib -L/usr/local/lib -L/usr/lib -L/usr/X11/lib -lpng15 -lz -lstdc++ -lm -o build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
drigz#mbp matplotlib 0$ python setup.py install
[SNIP]
drigz#mbp matplotlib 0$ otool -L /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so:
/usr/local/opt/libpng/lib/libpng15.15.dylib (compatibility version 29.0.0, current version 29.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 830.0.0)
I just wanted to add a few suggestions for people who might still be having trouble. I've been searching around for a while and trying lots of different things. Ultimately, it was one of the following that allowed me to import matplotlib.pyplot on Python 2.7.6 on OSX 10.6 (with X11 and XQuartz installed previously, perhaps outdated):
Installing pkg-info
brew install pkg-info
Installing libpng from source to /usr/local/lib (configure --libdir=/usr/local)
Installing XQuartz for Mac
Deleting matplotlib folders from site-packages (probably old, failed attempts).
Running
ln -s /usr/local/opt/freetype/include/freetype2 /usr/local/include/freetype
Finally,
port install py27-matplotlib
installed it, and I was able to import. The original error I had was
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.6-x86_64.egg/matplotlib/_png.so, 2): Library not loaded: /opt/local/lib/libpng15.15.dylib
Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.6-x86_64.egg/matplotlib/_png.so Reason: image not found
Though some attempts ran into this error:
In file included from src/ft2font.cpp:3:
In file included from src/ft2font.h:16:
/usr/X11/include/ft2build.h:56:10: fatal error: 'freetype/config/ftheader.h' file not found
#include <freetype/config/ftheader.h>
I'm sorry I can't be more specific.
You should follow these directions for installing Matplotlib from source on OSX: https://github.com/matplotlib/matplotlib/blob/master/README.osx
OSX is a bit messy with the lib files, but following the directions from the link should resolve any issues you're having as it automatically installs the dependencies in a self-contained manner.
I had same problem as OP. I git cloned the repo and "python setup install" instead of pre-compiled version. Took about 20 minutes to compile and seems to work now.
I'm trying to compile a python extension with cython in win 7 64-bit using mingw (64-bit).
I'm working with Python 2.6 (Active Python 2.6.6) and with the adequate distutils.cfg file (setting mingw as the compiler)
When executing
> C:\Python26\programas\Cython>python setup.py build_ext --inplace
I get an error saying that gcc has not an -mno-cygwin option:
> C:\Python26\programas\Cython>python setup.py build_ext --inplace
running build_ext
skipping 'hello2.c' Cython extension (up-to-date)
building 'hello2' extension
C:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python26\include -IC:\Python26\PC -c hello2.c -o build\temp.win-amd64-2.6\Release\hello2.o
gcc: error: unrecognized command line option '-mno-cygwin'
error: command 'gcc' failed with exit status 1
gcc is:
C:\>gcc --version
gcc (GCC) 4.7.0 20110430 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
How could I fix it?
It sounds like GCC 4.7.0 has finally removed the deprecated -mno-cygwin option, but distutils has not yet caught up with it. Either install a slightly older version of MinGW, or edit distutils\cygwinccompiler.py in your Python directory to remove all instances of -mno-cygwin.
During the process of solving these and the following problems I found, I wrote a recipe in this thread. I reproduce it here in case it could be of utility for others:
Step by step recipe to compile 64-bit cython extensions with python
2.6.6 with mingw compiler in win 7 64-bit
Install mingw compiler
1) Install tdm64-gcc-4.5.2.exe for 64-bit compilation
Apply patch to python.h
2) Modify python.h in C:\python26\include as indicated in
http://bugs.python.org/file12411/mingw-w64.patch
Modify distutils
Edit 2013: Note than in python 2.7.6 and 3.3.3 -mno-cygwin has been finally removed so step 3 can be skipped.
3) Eliminate all the parameters -mno-cygwin fom the call to gcc in the
Mingw32CCompiler class in Python26\Lib\distutils\cygwinccompiler.py
4) In the same module, modify get_msvcr() to return an empty list
instead of ['msvcr90'] when msc_ver == '1500' .
Produce the libpython26.a file (not included in 64 bit python)
Edit 2013: the following steps 5-10 can be skipped by downloading and installing libpython26.a from gohlke.
5) Obtain gendef.exe from mingw-w64-bin_x86_64-
mingw_20101003_sezero.zip
(gendef.exe is not available in the tmd64 distribution. Another
solution is to compile gendef from source...)
6) Copy python26.dll (located at C\windows\system32) to the user
directory (C:\Users\myname)
7) Produce the python26.def file with:
gendef.exe C:\Users\myname\python26.dll
8) Move the python.def file produced (located in the folder from where
gendef was executed) to the user directory
9) Produce the libpython.a with:
dlltool -v --dllname python26.dll --def C:\Users\myname
\python26.def --output-lib C:\Users\myname\libpython26.a
10) Move the created libpython26.a to C:\Python26\libs
Produce your .pyd extension
11) Create a test hello.pyx file and a setup.py file as indicated in
cython tutorial (http://docs.cython.org/src/quickstart/build.html)
12) Compile with
python setup.py build_ext --inplace
Done!
This bug has now been fixed in Python 2.7.6 release candidate 1.
The patching commit is here.
The resolved issue tracker thread is here.
Try this . It really works for the error
https://github.com/develersrl/gccwinbinaries