I am trying to read and learn the pytho2.5.6 source code, and try to recompile the code everytime i make some change on it.
But it doesn't seem to work when I comile the source code via the following commands:
./configure --prefix=/path/to/somewhere/that/don't/messup/myenv/
make
After make, the console just show errors like this:
cc1: error: unrecognized command line option "-Wno-long-double"
I search the google , and it seems like the gcc(4.2.1) that i am using is not compatiable with the python2.5.6.
some info of my sys:
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Xcode 4.6.2(installed via the xcode command cline tool )
python2.5.6 source code(download from python.org)
I have try some solutions like these:
1.download diff python code version , like 2.5.4, and do the steps again.
2.after configure,modify the Makefile,and remove the --Wno-long-double,but new errors showed like below:
➜ Python-2.5.6 make
gcc -c -fno-strict-aliasing -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c
In file included from Include/Python.h:57,
from Python/mactoolboxglue.c:26:
Include/pyport.h:547: warning: ‘struct winsize’ declared inside parameter list
Include/pyport.h:547: warning: its scope is only this definition or declaration, which is probably not what you want
Include/pyport.h:548: warning: ‘struct winsize’ declared inside parameter list
In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:67,
from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:38,
from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:18,
from /System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20,
from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:18,
from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
from Include/pymactoolbox.h:10,
from Python/mactoolboxglue.c:27:
/usr/include/AvailabilityMacros.h:109:14: warning: #warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid.
In file included from Python/mactoolboxglue.c:27:
.......
Python/mactoolboxglue.c: In function ‘MediaObj_Convert’:
Python/mactoolboxglue.c:431: error: ‘cobj’ undeclared (first use in this function)
Python/mactoolboxglue.c:431: error: too many arguments to function ‘PyMacGluePtr_MediaObj_Convert’
make: *** [Python/mactoolboxglue.o] Error 1
So, i wonder if there are some way to intall gcc4.0 manually?
PS:the reason why i use python2.5.6 is because i read a book called which is written in chinese.Or maybe the best solution is to read the 2.7 source code =.=....hmmm.....
Related
I am an Ultra Linux newbie, and I am trying to install this program and when I try to build the python wrapper I'd get this
~/Downloads/DeepMimic-master/DeepMimicCore$ make python
clang++ -c -g -std=c++11 -O3 -Wall -fPIC -I./ -I../../libraries/eigen -I../../libraries/bullet3/src -I/usr/include/python3.6m -I/usr/lib/ -lpython3.6m -o objs/Main.o Main.cpp
clang: warning: -lpython3.6m: 'linker' input unused [-Wunused-command-line-argument]
In file included from Main.cpp:3:
In file included from ./DeepMimicCore.h:3:
In file included from ./util/ArgParser.h:6:
./util/MathUtil.h:5:10: fatal error: 'Eigen/Dense' file not found
#include "Eigen/Dense"
You're missing a dependency, Eigen, which is listed under 'Dependencies' in the DeepMimic readme.
I see this problem has been encountered before:
fatal error: Eigen/Dense: No such file or directory
Looks like that program depends on Eigen. Try download Eigen and putting it in the appropriate directory.
Eigen is a template library, so you just have to download it, unzip it, and copy the folder called Eigen inside of the directory of the program.
Eigen website
I'm trying to compile a Python wrapper to a small C++ library I've written. I've written the following setup.py script to try to use setuptools to compile the wrapper:
from setuptools import setup, Extension
import numpy as np
import os
atmcmodule = Extension(
'atmc',
include_dirs=[np.get_include(), '/usr/local/include'],
libraries=['mcopt', 'c++'], # my C++ library is at ./build/libmcopt.a
library_dirs=[os.path.abspath('./build')],
sources=['atmcmodule.cpp'],
language='c++',
extra_compile_args=['-std=c++11', '-v'],
)
setup(name='tracking',
version='0.1',
description='Particle tracking and MC optimizer module',
ext_modules=[atmcmodule],
)
However, when I run python setup.py build on OS X El Capitan, clang complains about not finding some C++ standard library headers:
In file included from atmcmodule.cpp:7:
In file included from ./mcopt.h:11:
In file included from ./arma_include.h:4:
/usr/local/include/armadillo:54:12: fatal error: 'initializer_list' file not found
#include <initializer_list>
^
1 error generated.
error: command 'gcc' failed with exit status 1
Passing the -v flag to the compiler shows that it is searching the following include paths:
#include <...> search starts here:
/Users/[username]/miniconda3/include
/Users/[username]/miniconda3/lib/python3.4/site-packages/numpy/core/include
/usr/local/include
/Users/[username]/miniconda3/include/python3.4m
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1/backward
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.0.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks (framework directory)
End of search list.
This apparently doesn't include the path to the C++ standard library headers. If I compile a small test C++ source with the -v option, I can see that clang++ normally also searches the path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1, and if I include this path in the include_dirs option for Extension in my setup.py script, then the extension module compiles correctly and works. However, hard-coding this path into the script doesn't seem like a good solution since this module also needs to work on Linux.
So, my question is how do I properly make setuptools include the required headers?
Update (11/22/2015)
As setuptools tries to compile the extension, it prints the first command it's running:
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/[username]/miniconda3/include -arch x86_64 -I/Users/[username]/miniconda3/lib/python3.4/site-packages/numpy/core/include -I/Users/[username]/Documents/Code/ar40-aug15/monte_carlo/mcopt -I/usr/local/include -I/Users/[username]/miniconda3/include/python3.4m -c /Users/[username]/Documents/Code/ar40-aug15/monte_carlo/atmc/atmcmodule.cpp -o build/temp.macosx-10.5-x86_64-3.4/Users/[username]/Documents/Code/ar40-aug15/monte_carlo/atmc/atmcmodule.o -std=c++11 -fopenmp -v
If I paste this command into a terminal and run it myself, the extension compiles successfully. So I suspect either setuptools is modifying some environment variables I'm not aware of, or it's lying a little about the commands it's actually running.
Setuptools tries to compile C/C++ extension modules with the same flags used to compile the Python interpreter. After checking the flags used to compile my Python install (from Anaconda), I found it was compiling for a minimum Mac OS X version of 10.5. This seems to make it use the GCC libstdc++ instead of clang's libc++ (which supports C++11).
This can be fixed by either setting the environment variable MACOSX_DEPLOYMENT_TARGET to 10.9 (or later), or adding '-mmacosx-version-min=10.9' to extra_compile_args.
(UPDATE 3 contains the questions I'd like to get answers to. UPDATE 2 refers to corrections I did trying to understand and fix this issue)
I'm trying to get a Python extension module to wrap a C library (in this case, it is only an example described in the book Python Cookbook (3er edition.) The problem is that I'm encountering the classic error
ImportError: dynamic module does not define init function (initsample)
when I'm trying to import the module.
The book itself has the following comment:
For all of the recipes that follow, assume that the preceding code is found in a file named
sample.c, that definitions are found in a file named sample.h and that it has been com‐
piled into a library libsample that can be linked to other C code. The exact details of
compilation and linking vary from system to system, but that is not the primary focus.
It is assumed that if you’re working with C code, you’ve already figured that out.
And I think I'm getting that wrong. This is what I'm doing: First of all, I have the following files:
➜ Sample ls
csample.pxd sample.c sample.h sample.pyx setup.py
The content of the files is according to this github repository containing the files described in the book. Assuming everything is copied correctly. I then compile sample.c
➜ Sample gcc -c -fPIC -I/path/to/python2.7 sample.c
This creates sample.o and I proceed to create a shared library:
➜ Sample gcc -shared sample.o -o libsample.so
It creates a libsample.so and finally run the setup.py file:
➜ Sample python setup.py build_ext --inplace
running build_ext
skipping 'sample.c' Cython extension (up-to-date)
building 'sample' extension
creating build
creating build/temp.linux-x86_64-2.7
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/path/to/include/python2.7 -c sample.c -o build/temp.linux-x86_64-2.7/sample.o
gcc -pthread -shared build/temp.linux-x86_64-2.7/sample.o -L. -L/path/to/lib -lsample -lpython2.7 -o /path/to/sample.so
However, I obtain the same error. What am I missing?
This is my setup.py (eventually, I copied a part to clean previous build):
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
import sys
import os
import shutil
# clean previous build
for root, dirs, files in os.walk(".", topdown=False):
for name in files:
if (name.startswith("sample") and not(name.endswith(".pyx") or name.endswith(".pxd") or name.endswith(".h"))):
os.remove(os.path.join(root, name))
for name in dirs:
if (name == "build"):
shutil.rmtree(name)
ext_modules = [
Extension('sample',
['sample.pyx'],
libraries=['sample'],
library_dirs=['.'])]
setup(
name = 'Sample extension module',
cmdclass = {'build_ext': build_ext},
ext_modules = ext_modules
)
UPDATE 2
I was wondering if it is normal that after running
python setup.py build_ext --inplace
the file sample.c gets replaced with a cythonized version.
I assume that running setup.py is using cython sample.c, but I'm asking this because yesterday I was mistakenly compiling the cythonized version sample.c (after removing libsample.so, sample.o, sample.so that were created in a previous run) and after updating sample.pyx, I got this error:
>>> import sample
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: ./sample.so: undefined symbol: divide
After this, I restored sample.c to its original content, removed all remaining files from previous builds (including temporal files) and crucially, I had to change sample.pyx in some way (e.g. adding a blank line.)
I noticed I have to do this to avoid the
ImportError: dynamic module does not define init function (initsample)
error. Then I proceeded as usual:
➜ Sample gcc -c -fPIC -I/path/to/python2.7 sample.c
➜ Sample gcc -shared sample.o -o libsample.so
➜ Sample python setup.py build_ext --inplace
running build_ext
cythoning sample.pyx to sample.c
warning: sample.pyx:27:42: Use boundscheck(False) for faster access
building 'sample' extension
creating build
creating build/temp.linux-x86_64-2.7
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/path/to/include/python2.7 -c sample.c -o build/temp.linux-x86_64-2.7/sample.o
gcc -pthread -shared build/temp.linux-x86_64-2.7/sample.o -L. -L/path/to/lib -lsample -lpython2.7 -o /path/to/Sample/sample.so
➜ Sample python
>>> import sample
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: libsample.so: cannot open shared object file: No such file or directory
This time I get cythoning sample.pyx to sample.c in the output above and a new error. However, libsample.so is in the Sample directory. What could be the issue here?
UPDATE 3:
I finally was able to import this module successfully but the last error
ImportError: libsample.so: cannot open shared object file: No such file or directory
implied that I needed to set the current directory in the environment variable LD_LIBRARY_PATH. However, I did it in a crude way:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/Sample
What is the correct way to do this? Maybe using some parameter in setup.py? Regarding the several issues I found, I'd like to get an answer as to why all of this happened:
sample.c gets replaced when running python setup.py build_ext --inplace Is this okay?
Do I need to restore sample.c every time I'm doing this procedure?
Do I need to change sample.pyx in order to get a correct output (instead of skipping 'sample.c' Cython extension (up-to-date) with a misleading output)
What is the correct way to solve ImportError: libsample.so: cannot open shared object file: No such file or directory?
A possible solution to 4. is to add in setup.py:
runtime_library_dirs=['./'],
However, this requires libsample.so to be located in the same directory as setup.py.
I'm having trouble installing Python 3.3 on Cygwin. I've tried installing from source, but make returns:
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/signalmodule.c -o Modules/signalmodule.o
In file included from Include/Python.h:84:0,
from ./Modules/signalmodule.c:6:
./Modules/signalmodule.c: In function `fill_siginfo':
./Modules/signalmodule.c:745:60: error: `siginfo_t' has no member named `si_band'
PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
^
Include/tupleobject.h:62:75: note: in definition of macro `PyTuple_SET_ITEM'
#define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i] = v)
^
./Modules/signalmodule.c:745:5: note: in expansion of macro `PyStructSequence_SET_ITEM'
PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
^
Makefile:1501: recipe for target `Modules/signalmodule.o' failed
make: *** [Modules/signalmodule.o] Error 1
Makefile:1501: recipe for target 'Modules/signalmodule.o' failed
make: ***[Modules/signalmodule.o] error 1
Any thoughts?
Building Python on Cygwin is not trivial -- I tried. However, the Python community on its bug tracker website is unusually friendly and gentle for a project its size and importance. If you find specific issues, open bugs and follow the discussion. Usually, they will accept tiny patches to fix Cygwin build issues.
This patch will solve your first problem about si->si_band. See related Python issue #21085.
This blog post (in German) is amazing. It will walk you through step-by-step how to build Python3.4 and fix all Cygwin issues.
Good luck. You will need it.
I am having the identical problem as mentioned in this thread when I try to install Python 2.5.6 on Lion: Python 2.5.6 build error on Mac Lion
Specifically, the error I receive is when attempting a make is:
/usr/bin/gcc-4.2 -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
cc1: error: unrecognized command line option "-Wno-long-double"
make: *** [Modules/python.o] Error 1
In my case, it is as a result of me deleting the python 2.5 folder thinking I would never need it while I was troubleshooting another problem.
Now, when I try to launch Google App Engine, I get the error: "Sorry, pieces of GoogleAppEngineLauncher.app appear missing or corrupted, or I can't run python2.5 properly" and then it shuts down, so unfortunately I can't just ignore the problem as is recommended in the previous thread.
EDIT:
It looks like I messed things up pretty royally by deleting the folder. The solution (though I haven't implemented it yet) is described here: Mac Python "Installation step failed: run postflight script"
EDIT x2:
Solved it! Though I have no idea what kind of damage I've done. I ran the .DMG installer, and even though it failed it placed the folder for Python 2.5.4. in /Library/Frameworks/Python.framework/Versions. I then copied that along with 2.7 into the /System/Library/Frameworks/Python.framework/Versions folder. After that, launched Google App Engine and everything worked! (For now.)
I think your best bet is to install the Universal Binary provided for OS X, see http://www.python.org/ftp/python/2.5.4/python-2.5.4-macosx.dmg .
This is well documented on http://docs.python.org/2/using/mac.html.