Am 23.08.2015 um 21:01 schrieb Andreas Kloeckner
Gregor Thalhammer <gregor.thalhammer(a)gmail.com> writes:
with current master I was now able to successfully build pyopencl with Anaconda Python
2.7 on Mac OS 10.10. To succeed, I had to edit siteconf.py, adding
'-mmacosx-version-min=10.7‘ to CXXFLAGS and LDFLAGS, otherwise I obtain an error:
clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or
OK, I've added that to the default build options for OS X.
On OS X I tried also with OpenGL interoperability
enabled, this gives an error:
AttributeError: 'module' object has no attribute ‚get_apple_cgl_share_group‘. I
will try to investigate this further and report back.
Great, thank you!
On Windows 7 64bit with Anaconda Python 2.7 and
the free Microsoft
Compiler I failed building current master. To my understanding, the
Microsoft compiler only supports old C++ dialects. So MinGW is
required to build pyopencl on Windows?
This page details their claimed level of support:
Could you report which specific feature the compiler doesn't like?
Perhaps that could be worked around.
I am glad to report that I finally managed to build recent pyopencl master on Windows 7
(64bit), with Anaconda Python 2.7 (64bit), and wrapper tests pass.
Here a summary of the issues I encountered:
* Building with Microsoft Visual Studio 2008 is hopeless, it misses all the new C++
features (even the integer types such as uint64_t) used throughout pyopencl.
* Instead I used the mingw compiler toolchain (carlkl/mingwpy 0.1.0b3 from binstar, gcc
4.9.2, x86_64-win32-seh-rev201506), with CXXFLAGS -std=c++11, (also c++0x is ok) and
python setup.py build_ext -—compiler=mingw32
* This toolchain, built with win32 thread support, does not support std::mutex or
std::thread. One solution I found is to use
which provides the missing functions. In debug.h I added
* In pyopencl the OpenCL constants end up as int attributes of Python classes. However, on
Windows a Python int is only 32bit, too small to hold e.g. device_type.ALL, which is
defined with a value of 0xFFFFFFFF (but got wrapped to -1, which evokes errors).
In wrap_constants.cpp I changed the signature for the last argument (value) of
populate_constants() from long to unsigned long (actually, shouldn’t this be a cl_uint?)
The changes I applied to the source are attached as a patch file. No idea if these are a
proper way to resolve the issues, nor made I an attempt to make them platform specific.