Am 02.07.2015 um 01:39 schrieb Andreas Kloeckner
Thanks very for much for reporting your test results!
Gregor Thalhammer <gregor.thalhammer(a)gmail.com> writes:
> gave it a quick try on a Mac (OS X 10.10.3) with Anaconda Python 2.7. My observation
when building pyopencl master branch:
> * you need a recent cffi
setup.py states a dependency on cffi>=1.1.0 (which is indeed quite
recent) for both initial build and installation, this should pull in the
required package automatically. Did it do that for you?
thanks for your help, I am not experienced with building packages, these have been helpful
Yes, I can see that requirement in setup.py, but for me, when building the package with
python setup.py build -f
this did not happen. I have setup tools
> * on a Mac, the OpenCL headers reside in <OpenCL/…>, changed this in
> * same for OpenGL headers, live in <OpenGL/…>
> * still building fails with an error (only showing first error):
> gcc -fno-strict-aliasing -fwrapv -Wall -O3 -DNDEBUG -DPYGPU_PACKAGE=pyopencl
-DPYGPU_PYOPENCL=1 -DPYOPENCL_USE_DEVICE_FISSION=1 -DHAVE_GL=1 -Isrc/c_wrapper/
-I/Users/gregor/anaconda/include/python2.7 -c src/c_wrapper/wrap_cl.cpp -o
build/temp.macosx-10.5-x86_64-2.7/src/c_wrapper/wrap_cl.o -std=c++0x -arch i386 -arch
> In file included from src/c_wrapper/wrap_cl.cpp:1:
> In file included from src/c_wrapper/pyhelper.h:5:
> src/c_wrapper/function.h:14:32: error: no type named 'remove_reference' in
> namespace 'std'
> using rm_ref_t = typename std::remove_reference<T>::type;
> seems you are using C++ language features too recent for a Mac :-(
> my result for 'gcc -v'
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
> Target: x86_64-apple-darwin14.3.0
> Thread model: posix
I had a chance to try on OS X 10.10.4 today, where 'gcc -v' says this:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Thread model: posix
Strange, this seems to be nearly the same compiler, except from the more recent target. I
will see if I have the latest compiler from Apple installed
Aside from a few run-time issues involving complex numbers that resemble
this pocl bug , everything worked.
> I also tried a more recent gcc (4.9, installed with homebrew) without success:
> $export CC=gcc-4.9; python setup.py build
> gives a huge amount of compile errors similar to:
> /var/folders/4x/v77nr78x5cs7l2rjscx147th0000gn/T//ccHwGSd1.s:8:bad register name
And it does this only for PyOpenCL?
Googling led me to this:
> Hello,Looks like you have 32bit binutils where as gcc is trying to do
> a 64bit build. Make sure your binutils & gcc has the same
> configuration.By default the GNSDK makefiles will build using the
> 64-bit libraries on Mac OS X. You can force a 32-bit build by typing:
> make ARCH=i386
PyOpenCL tries to do a fat-binary build (32- and 64-bit
simultaneously). %rdi is a 64-bit register. If you nuke the references
to x86_64 in setup.py, does this still happen?
You are right, these errors have been to 32/64 issues. I think I built my gcc-4.9 only for
64-bit. I removed the -arch i386 flags in siteconf.py and setup.py, and the errors are
Next roadblock is this error:
error: expected unqualified-id before '^' token
typedef void (^dispatch_block_t)(void);
after patching …/dispatch/object.h according to
it compiles. Next step is to test it, but I need more time for this.