> Am 02.07.2015 um 01:39 schrieb Andreas Kloeckner <[email protected]>: > > 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?
Dear Andreas, thanks for your help, I am not experienced with building packages, these have been helpful remarks. 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 17.1.1 installed. > >> * 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 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 [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? 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 gone. Next roadblock is this error: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/dispatch/object.h:143:15: error: expected unqualified-id before '^' token typedef void (^dispatch_block_t)(void); after patching …/dispatch/object.h according to http://hamelot.co.uk/programming/osx-gcc-dispatch_block_t-has-not-been-declared-invalid-typedef/ it compiles. Next step is to test it, but I need more time for this. Gregor > > Andreas _______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
