>> import pyopencl

Traceback (most recent call last): File "<stdin>", line 1, in <module> File "pyopencl/__init__.py", line 3, in <module> import pyopencl._cl as _cl ImportError: No module named _cl

Jake-Ross-Computer:pyopencl-0.91 Ross$ CC=gcc-4.0 make ctags -R src || true ctags: illegal option -- R usage: ctags [-BFadtuwvx] [-f tagsfile] file ... /Library/Frameworks/Python.framework/Versions/5.0.0/Resources/ Python.app/Contents/MacOS/Python setup.py build running build running build_py running build_ext building '_cl' extension gcc-4.0 -fno-strict-aliasing -no-cpp-precomp -mno-fused-madd -fno- common -dynamic -I/Library/Frameworks/Python.framework/Versions/ 5.0.0/include -O3 -DNDEBUG -Isrc/cpp -I/Users/Ross/Boost/include -I/ Library/Frameworks/Python.framework/Versions/5.0.0/lib/python2.5/ site-packages/numpy/core/include -I/Library/Frameworks/ Python.framework/Versions/5.0.0/include/python2.5 -c src/wrapper/ wrap_cl.cpp -o build/temp.macosx-10.3-i386-2.5/src/wrapper/ wrap_cl.o -arch i386 -arch x86_64 -isysroot /Developer/SDKs/ MacOSX10.6.sdk In file included from /Developer/SDKs/MacOSX10.6.sdk/System/Library/ Frameworks/OpenCL.framework/Headers/opencl.h:12, from src/wrapper/wrap_cl.hpp:15, from src/wrapper/wrap_cl.cpp:1: /Developer/SDKs/MacOSX10.6.sdk/usr/include/AvailabilityMacros.h: 108:14: warning: #warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid. In file included from /Developer/SDKs/MacOSX10.6.sdk/System/Library/ Frameworks/OpenCL.framework/Headers/opencl.h:12, from src/wrapper/wrap_cl.hpp:15, from src/wrapper/wrap_cl.cpp:1: /Developer/SDKs/MacOSX10.6.sdk/usr/include/AvailabilityMacros.h: 108:14: warning: #warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid. In file included from /Library/Frameworks/Python.framework/Versions/ 5.0.0/include/python2.5/Python.h:57, from /Users/Ross/Boost/include/boost/python/detail/ wrap_python.hpp:142, from /Users/Ross/Boost/include/boost/python/detail/ prefix.hpp:13, from /Users/Ross/Boost/include/boost/python/ args.hpp:8, from /Users/Ross/Boost/include/boost/python.hpp:11, from src/wrapper/wrap_helpers.hpp:8, from src/wrapper/wrap_cl.hpp:38, from src/wrapper/wrap_cl.cpp:1: /Library/Frameworks/Python.framework/Versions/5.0.0/include/ python2.5/pyport.h:761:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." lipo: can't figure out the architecture type of: /var/folders/HR/ HR4MJfTvGmSHMD5GW6NlvU+++TI/-Tmp-//ccIFYar5.out error: command 'gcc-4.0' failed with exit status 1 make: *** [all] Error 1

import sys #====================filtier out -Wno-long-double============== from distutils import sysconfig cvars = sysconfig.get_config_vars() cflags = cvars.get('BASECFLAGS') cvars['BASECFLAGS']='-fno-strict-aliasing -no-cpp-precomp -mno- fused-madd -fno-common -dynamic' #==============================================================

Hmm.. again, this is a distutils related issue. It looks like you've got the latest EPD (guessing from the 5.0.0 in your path) and they likely compiled it with a 10.3 target using gcc 4.0.1 (or similar), and they seem to have used a generic "gcc" rather than specifying a particular version like "gcc-4.0" when they did the build. First, make sure that when you are building boost it's building for that python install, and not Apple's (if you're wanting to use that python install). I think it should display which version it has selected in some of the output prior to the full build stage. Second, you'll either need to filter out that "-Wno-long-double" from the CFLAGS/CXXFLAGS that distutils is putting together, or try building with gcc-4.0.1. For pyopencl, the following seems to force using gcc-4.0.1: CC=gcc-4.0 make It's also possible that something similar may be needed for boost, although a quick test using Apple's Python 2.6.1 and boost having been built with gcc 4.2 and rebuilding pyopencl with the above gcc-4.0 appears to work. Good luck :-) -jsnyder P.S.: Anyone know of any guides out there that lay out some general rules for working around these issues when one has multiple python installs that might have been built using different compilers and are installed in different places? This seems to be somewhat unique to OS X due to Apple always providing a python install, but users frequently install pre-packaged python distributions. Andreas: It looks like hack_distutils() or something similar with aksetup_helper could be modified to pick up on situations like this? On Sep 16, 2009, at 12:03 AM, Jake Ross wrote: