Ugh, so many issues. Sorry about that, and thanks for taking the time to list them. I'll work on fixing them. CC'ing the list so they're staying informed on what's up.
Andreas Christoph Gohlke <[email protected]> writes: > <[email protected]> bounced. Resending to <[email protected]>. > > > Hi Andreas, > > sorry for the delay. > > I tried building PyOpenCL 2015.2.x on Windows and noticed several issues: > > > 1. The PyPI source distribution is missing src/c_wrapper/mingw-std-threads. > > Using git master for now. > > > 2. Setup.py fails if git not found. > > Using this workaround: > > diff --git a/aksetup_helper.py b/aksetup_helper.py > index b7378b5..29ed40a 100644 > --- a/aksetup_helper.py > +++ b/aksetup_helper.py > @@ -703,6 +703,7 @@ def substitute(substitutions, fname): > def _run_git_command(cmd): > git_error = None > from subprocess import Popen, PIPE > + stdout = None > try: > popen = Popen(["git"] + cmd, stdout=PIPE) > stdout, stderr = popen.communicate() > @@ -722,8 +723,11 @@ def _run_git_command(cmd): > print(git_error) > print("Hit Ctrl-C now if you'd like to think about the > situation.") > print(DASH_SEPARATOR) > - count_down_delay(delay=5) > - return stdout.decode("utf-8"), git_error > + count_down_delay(delay=0) > + if stdout: > + return stdout.decode("utf-8"), git_error > + else: > + return '', None > > > def check_git_submodules(): > > > 3. PyOpenCL 2015.2.x was apparently rewritten specifically for gcc > compilers. The default platform compilers for Python on Windows, Visual > Studio 2008, 2010, and 2015 no longer compile the code. Same for Intel > Compilers 2013 and 2016. Too many different errors to report. > > The workaround is to use mingwpy compilers. However, they do not support > Python 3.5, I can not debug the builds, and cffi might have issues: > > pyopencl._cffi.cpp:365:68: warning: unknown conversion type character > 'z' in format > > > 4. strdup failed to link: > > wrap_cl.cpp:(.text+0x42f): undefined reference to `strdup' > > Using _strdup instead: > > diff --git a/src/c_wrapper/wrap_cl.h b/src/c_wrapper/wrap_cl.h > index 41e57c2..576de6c 100644 > --- a/src/c_wrapper/wrap_cl.h > +++ b/src/c_wrapper/wrap_cl.h > @@ -31,6 +31,7 @@ > #if defined(_WIN32) > #define NOMINMAX > #include <windows.h> > +#define strdup _strdup > #else > #include <unistd.h> > #endif > > > 5. CL_KERNEL_ARG_TYPE_const' was not declared in this scope: > > src/c_wrapper/wrap_constants.cpp:8:24: error: 'CL_KERNEL_ARG_TYPE_const' > was not declared in this scope > > Disabling CL_KERNEL_ARG_TYPE_const for now: > > diff --git a/src/c_wrapper/wrap_constants.cpp > b/src/c_wrapper/wrap_constants.cpp > index 0685b1f..661d7e8 100644 > --- a/src/c_wrapper/wrap_constants.cpp > +++ b/src/c_wrapper/wrap_constants.cpp > @@ -613,7 +614,7 @@ void populate_constants(void(*add)(const char*, > const char*, int64_t value)) > // kernel_arg_type_qualifier > #if PYOPENCL_CL_VERSION >= 0x1020 > ADD_ATTR("kernel_arg_type_qualifier", KERNEL_ARG_TYPE_, NONE); > - ADD_ATTR("kernel_arg_type_qualifier", KERNEL_ARG_TYPE_, CONST); > + //ADD_ATTR("kernel_arg_type_qualifier", KERNEL_ARG_TYPE_, CONST); > ADD_ATTR("kernel_arg_type_qualifier", KERNEL_ARG_TYPE_, RESTRICT); > ADD_ATTR("kernel_arg_type_qualifier", KERNEL_ARG_TYPE_, VOLATILE); > #endif > > > 6. 32 bit build fails with: > > src/c_wrapper/error.h:255:35: error: invalid conversion from 'cl_int > (__attribute__((__stdcall__)) *)(cl_mem) {aka int > (__attribute__((__stdcall__)) *)(_cl_mem*)}' to 'cl_int (*)(_cl_mem*) > {aka int (*)(_cl_mem*)}' [-fpermissive] > call_guarded(func, #func, args) > > > 7. 64 bit builds succeed and pyopencl can be imported, but running any > test results in immediate segfaults in _cffi.pyd. > > I used latest CUDA and Intel OpenCL SDKs. CFFI is version 1.3.1, > compiled with Visual Studio. I'll try to debug the crash when I find the > time. > > > Greetings to Urbana-Champaign. I worked at Loomis Lab for ~8 years. > > Christoph > > > > On 12/3/2015 2:53 PM, Andreas Kloeckner wrote: >> Christoph, >> >> Zac Diggum (cc'd) reported that you had some trouble getting PyOpenCl to >> compile on Windows. That makes sense since the 2015.2 series is >> essentially a rewrite of the wrapper. I'd be interested in hearing what >> trouble you ran into, and if I can somehow help getting it to >> work. Could you report what issues you ran into? >> >> Thanks! >> Andreas >> > _______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
