I'm trying to install matplotlib for Python on MacOS X. If I use the system Python 2.6.1, the default compiler commands that matplotlib uses (presumably via distutils) are::
gcc-4.2 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes
g++-4.2 -Wl,-F. -bundle -undefined dynamic_lookup
However, if I simply add the python.org 2.6.6 Python to the PATH to use that instead, the default compilers suddenly change to
gcc-4.0 -DNDEBUG -g -O3
c++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk \
-g -bundle -undefined dynamic_lookup
This causes issues, so I was wondering what determines which C compilers are used when running python setup.py install? Why does using the python.org Python mean that different default compiler commands are used?
The python.org release is designed to work just as well on MacOsX 10.5 as on 10.6, therefore of course it has to stick with a gcc release that is commonly available for both. Apple's system Python, of course, labors under no such constraint -- it supports only a very specific version of MacOsX and therefore can use the "latest and greatest" gcc available for that one specific version... and so of course it does;-).
Related
You may have following issue while compiling python packages on Mac:
cc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -arch i386 -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch x86_64 -arch i386 -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c src/misaka.c -o build/temp.macosx-10.9-intel-2.7/src/misaka.o
cc: error: unrecognized command line option '-Wshorten-64-to-32'
error: command 'cc' failed with exit status 1
Solution is to run commands below:
export CC=/usr/bin/clang
export CXX=/usr/bin/clang++
If you see this problem on a Mac OS X system, it is likely because you are running Python2.7 and using distutils.
By default, Python2.7 on Mac OS X is compiled with the alias "cc". At compile time, "cc" refers to "clang". Clang is the default program that Apple uses to compile C and C++ code.
Solution 1
The most appropriate solution is to ensure that "cc" refers to the correct compiler on your Mac OS X distribution. Try typing into the terminal:
ls -l `which cc`
If the output does not resolve to "/usr/bin/cc -> clang", or something similar that points to clang, then you should fix this by removing (or relabelling) "cc" programs in your path that do not point to clang.
If you have installed gcc or some other c/c++ compiler then it may have added a link to your path that refers "cc" to a different compiler. This is not recommended, because other compilations in the system that rely on cc referring to clang, or have used cc in the past expecting clang may fail. A prime example is what brought you to this page.
Solution 2
As mentioned by Igor you can type in the terminal before executing python setup code and/or compiling python code:
export CC=/usr/bin/clang
export CXX=/usr/bin/clang++
Solution 3
You can also set these options inside of python with:
import os
os.environ["CC"] = "clang"
os.environ["CXX"] = "clang++"
I am tying to build PIL 1.1.7 on Mac OS X 10.7, I am getting this error:
running build
running build_py
running build_ext
--- using frameworks at /System/Library/Frameworks
building '_imaging' extension
gcc-4.0 -fno-strict-aliasing -fno-common -dynamic -arch ppc -arch i386 -g -O2 -DNDEBUG -g -O3 -DHAVE_LIBZ -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -IlibImaging -I/opt/local/include -I/Library/Frameworks/Python.framework/Versions/2.6/include -I/usr/include -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c _imaging.c -o build/temp.macosx-10.3-fat-2.6/_imaging.o
unable to execute gcc-4.0: No such file or directory
error: command 'gcc-4.0' failed with exit status 1
I have the latest Xcode installed. gcc-4.0 does not exist but gcc-4.2 does. I don't know why it's trying to use gcc-4.0.
You appear to be using a 32-bit-only Python possibly one downloaded from python.org. They are built with gcc-4.0 and for the i386 and ppc archs for compatibility with multiple OS X versions. When building a C extension module, Python's Distutils will attempt to use the same compiler version and options that Python itself was build with. Because gcc-4.0 and support for the ppc architecture are no longer included with Xcode 4 and OS X 10.7, you should not use the 32-bit-only builds on 10.7 if you need to build extension modules. Either install a 64-bit/32-bit version of Python (2.7.2 and 3.2.2 are current from python.org) or use the Apple-supplied system Pythons in 10.7 (/usr/bin/python which defaults to 2.7.1).
I followed the installation instructions for installing oursql on Mac OS X. Since
sudo pip install oursql
told me, that it couldn't find mysql_config I (located it with locate mysql_config and) told it where to find it by
sudo MYSQL_CONFIG=/usr/local/mysql-5.5.14-osx10.6-x86_64/bin/mysql_config pip install oursql
I added the terminal output at the bottom for readability reasons. After that I fired up python in terminal (On Mac OS Lion it is python 2.7 now,...) and did
>>> import oursql
but python keeps telling me:
>>> import oursql
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen(/Library/Python/2.7/site-packages/oursql.so, 2): Library not loaded: libmysqlclient.18.dylib
Referenced from: /Library/Python/2.7/site-packages/oursql.so
Reason: image not found
What do I miss? Any suggestions?
Terminal Output, of pip installation:
Downloading/unpacking oursql
Downloading oursql-0.9.2.tar.bz2 (113Kb): 113Kb downloaded
Running setup.py egg_info for package oursql
Installing collected packages: oursql
Running setup.py install for oursql
skipping 'oursqlx/oursql.c' Cython extension (up-to-date)
building 'oursql' extension
/usr/local/mysql-5.5.14-osx10.6-x86_64/bin/mysql_config --cflags
llvm-gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c oursqlx/oursql.c -o build/temp.macosx-10.7-intel-2.7/oursqlx/oursql.o -I/usr/local/mysql-5.5.14-osx10.6-x86_64/include -Os -g -fno-common -fno-strict-aliasing -arch x86_64
oursqlx/oursql.c: In function ‘__pyx_pf_6oursql_10Connection___cinit__’:
oursqlx/oursql.c:4630: warning: implicit conversion shortens 64-bit value into a 32-bit value
oursqlx/oursql.c: In function ‘__pyx_pf_6oursql_10_Statement_execute’:
oursqlx/oursql.c:10219: warning: implicit conversion shortens 64-bit value into a 32-bit value
oursqlx/oursql.c: In function ‘__pyx_pf_6oursql_16_DBAPITypeObject___richcmp__’:
oursqlx/oursql.c:17597: warning: implicit conversion shortens 64-bit value into a 32-bit value
llvm-gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c oursqlx/compat.c -o build/temp.macosx-10.7-intel-2.7/oursqlx/compat.o -I/usr/local/mysql-5.5.14-osx10.6-x86_64/include -Os -g -fno-common -fno-strict-aliasing -arch x86_64
/usr/local/mysql-5.5.14-osx10.6-x86_64/bin/mysql_config --libs
llvm-gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -Wl,-F. -arch i386 -arch x86_64 build/temp.macosx-10.7-intel-2.7/oursqlx/oursql.o build/temp.macosx-10.7-intel-2.7/oursqlx/compat.o -o build/lib.macosx-10.7-intel-2.7/oursql.so -L/usr/local/mysql-5.5.14-osx10.6-x86_64/lib -lmysqlclient -lpthread
ld: warning: ignoring file build/temp.macosx-10.7-intel-2.7/oursqlx/oursql.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: ignoring file build/temp.macosx-10.7-intel-2.7/oursqlx/compat.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: ignoring file /usr/local/mysql-5.5.14-osx10.6-x86_64/lib/libmysqlclient.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
Successfully installed oursql
Cleaning up...
This did the job:
export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/usr/local/mysql/lib/"
If you don't want to install a full MySQL you can compile oursql with the mysql-connector-c.
Download mysql-connector-c, unzip and install:
wget http://dev.mysql.com/get/Downloads/Connector-C/mysql-connector-c-6.0.2-osx10.5-x86-64bit.tar.gz/from/http://cdn.mysql.com/
tar -xvf mysql-connector-c-6-1.0.2-osx10.5-x86-64bit.tar
cd mysql-connector-c-6.0.2-osx10.5-x86-64bit
sudo cp bin/* /usr/local/bin/
sudo cp lib/* /usr/local/lib/
sudo cp -r include/* /usr/local/include/
Download and unzip oursql:
wget --no-check-certificate https://launchpad.net/oursql/py3k/py3k-0.9.3/+download/oursql-0.9.3.zip
unzip oursql-0.9.3.zip
Compile oursql:
cd oursql-0.9.3
sudo python setup.py build_ext
This has been verified to work with OSX 10.8.2, Xcode 4.5.2 and Python 3.2.3
I came across this question looking for a solution to installing oursql on OSX 10.10.5. I had previously installed mysql using brew brew install mysql. For those looking to install oursql on yosemite, here is what works for me:
1) Download the package manually. See links here.
2) Open oursql/oursql-0.9.3.1/oursqlx/_exceptions.c in your favourite text editor
3) Comment the last “default”, should look something like this:
/*default:
if (err >= ER_ERROR_FIRST && err <= ER_ERROR_LAST)
return _oursqlx_ProgrammingError;
else if (err > CR_MIN_ERROR && err < CR_MAX_ERROR)
return _oursqlx_InterfaceError;*/
4) Now try running setup again:
[sudo] python setup.py install
The best way for installing mysql-server on mac os snow leopard is trying to install from source file in order to make sure you are compiling mysql for the correct architecture x86_64.
I use Python on Mac OS X version 10.6. I recently installed the newest Mac OS X developer tools SDK, which has GCC in it. The SDKs I have are:
$ ls /Developer/SDKs/
MacOSX10.4u.sdk MacOSX10.5.sdk MacOSX10.6.sdk
I'd like to use Mac OS X 10.6 with Python/distutils, whenever I install a python package with "setup.py install" that requires compilation.
I notice that Python passes the -isysroot flags and paths to Mac OS X 10.5 (not 10.6), i.e.:
$ python-config --cflags --ldflags
-I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -I/Library/Frameworks/EPD64.framework/Versions/7.0/include
-L/Library/Frameworks/EPD64.framework/Versions/7.0/lib/python2.7/config -ldl -framework CoreFoundation -lpython2.7 EPD64.framework/Versions/7.0/Python
How can I correct this? I'd like it to use the 10.6 SDK instead.
Right now when I run "python setup.py install" on a package that requires C compilation, it yields calls to GCC that look like this:
gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -I/Library/Frameworks/EPD64.framework/Versions/7.0/include -DHAVE_RINTF=1 -DHAVE_FINITE=1 -DHAVE_EXPM1=1 -DHAVE_RINT=1 -DHAVE_LOG2=1 -DHAVE_LOGBL=1 -DHAVE_SNPRINTF=1 -DHAVE_LOG1P=1 -DHAVE_ROUND=1 -DHAVE_FMIN=1 -Iinclude -Isrc/lapack -Isrc/f2c -I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -c src/f2c/signal_.c -o build/temp.macosx-10.5-x86_64-2.7/src/f2c/signal_.o
which calls 10.5 SDKs in its path.
I use the Enthought Python Distribution installation of Python in case that makes a difference.
Thanks very much.
It's a feature and should not cause you any worries. Distutils does this deliberately to ensure that C extension modules that you build are built the same way that the Python interpreter in use was built. Extensions built this way are upwards compatible: they will work on 10.6 as well. If you absolutely want to use 10.6 ABI features, you should use a Python that was built using the 10.6 SDK, for instance, from a recent python.org 64-bit installer or from MacPorts or Homebrew.
I completely disagree with #Ned Deily
The poster obviously uses Enthought Python Distribution (EPD), and installing the whole new Python would require an installation of the whole new infrastracture.
I have the same situation. On MacBook with Mac Os X 10.6 the project (MeshPy) builds correctly, but on the Imac with Mac Os X 10.7 it does not (no 10.5 SDK is provided, and with this SDK EPD was built). You can try to install this old SDK, however, a much simpler hack (hopefully it works) is to make a symlink:
sudo ln -sf MacOSX10.6.sdk MacOSX10.5.sdk
It worked for me.
I've taken a library that is distributed as a binary lib (.a) and header, written some c++ code against it, and want to wrap the results up in a python module.
I've done this here.
The problem is that when importing this module on Mac OSX (I've tried 10.5 and 10.6), I get the following error:
dlopen(/Library/Python/2.5/site-packages/dirac.so, 2): Symbol not found: _DisposePtr
Referenced from: /Library/Python/2.5/site-packages/dirac.so
Expected in: dynamic lookup
This looks like symbols defined in the Carbon framework aren't being properly resolved, but I'm not sure what to do about that. I am supplying -framework Carbon to distutil.core.Extension's extra_link_args parameter, so I'm not sure what else I should do.
Any help would be much appreciated.
Update:
The compile line generated by setup.py looks like this:
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE -arch i386 -arch ppc -pipe -Isource -I/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/numpy/core/include -I/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/numpy/numarray -I/usr/lib/python/2.5/site-packages/numpy/numarray/numpy -I/usr/lib/python/2.5/site-packages/numpy/numarray -I/usr/lib/python/2.5/site-packages/numpy/core/include -I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c source/Dirac_LE.cpp -o build/temp.macosx-10.5-i386-2.5/source/Dirac_LE.o
The linker line looks like this:
g++ -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc build/temp.macosx-10.5-i386-2.5/diracmodule.o build/temp.macosx-10.5-i386-2.5/source/Dirac_LE.o -Llibs/MacOSX -lDiracLE -o build/lib.macosx-10.5-i386-2.5/dirac.so -framework Carbon
otool reports:
dirac.so:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/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 111.1.5)
Update 2:
On MacOS 10.5, modifying the dlopen flags from the default of RTLD_NOW to RTLD_LAZY solves the problem. However, this does not work on Mac OS 10.6.
On 10.6, the following sequence allows the library to run properly, although I'm not sure why:
python setup.py build -v
run the linker line (printed to console by setup.py) again, manually.
python setup.py install
I'm still looking for a good answer as to how to get this to work properly. Thanks!
You're going to kick yourself when you see the answer to this! Try changing this:
link_args = ['-framework Carbon'] if platform == 'Darwin' else []
to this:
link_args = ['-framework', 'Carbon'] if platform == 'Darwin' else []
Once I made this change I was able to do a clean build and import the module straight away :)