Gregor, Thanks very for much for reporting your test results!
Gregor Thalhammer <[email protected]> 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? > * on a Mac, the OpenCL headers reside in <OpenCL/…>, changed this in > cffi_build.py.in Fixed. > * same for OpenGL headers, live in <OpenGL/…> Fixed. > * 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 x86_64 -isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk > 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 > --with-gxx-include-dir=/usr/include/c++/4.2.1 > 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 --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.4.0 Thread model: posix Aside from a few run-time issues involving complex numbers that resemble this pocl bug [1], everything worked. [1] https://github.com/pocl/pocl/issues/197 > 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 `%rdi)' > / And it does this only for PyOpenCL? Googling led me to this: https://developer.gracenote.com/cant-compile-sdk-under-mac-os-x-1082?language=ja which says: > 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? Andreas
signature.asc
Description: PGP signature
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
