ocl_icd_loader_gen.c:4613:3: error: initialization of 'cl_int (__attribute__((stdcall)) *)(struct _cl_command_queue *, void *, cl_uint, struct _cl_event * const*, struct _cl_event **)' {aka 'int (__attribute__((stdcall)) *)(struct _cl_command_queue *, void *, unsigned int, struct _cl_event * const*, struct _cl_event **)'} from incompatible pointer type 'cl_int (*)(struct _cl_command_queue *, void *, cl_uint, struct _cl_event * const*, struct _cl_event **)' {aka 'int (*)(struct _cl_command_queue *, void *, unsigned int, struct _cl_event * const*, struct _cl_event **)'} [-Wincompatible-pointer-types]
4613 | clEnqueueSVMUnmap_disp,
| ^~~~~~~~~~~~~~~~~~~~~~
ocl_icd_loader_gen.c:4613:3: note: (near initialization for 'master_dispatch.clEnqueueSVMUnmap')
The mismatch here is the
I naively started working on a build of ocl-icd for MSYS2 in msys2/MINGW-packages#22623, but encountered several issues that seemed to indicate the code currently isn't really compatible with Windows environments. I don't have the time to fix these myself, but figured it would be useful to open an issue tracking what (some of) the remaining problems are:
libtool: error: can't build x86_64-w64-mingw32 shared library unless -no-undefined is specified, for which Cygwin has a patch: https://cygwin.com/cgit/cygwin-packages/ocl-icd/tree/ocl-icd-2.3.2-1.src.patchlld: error: unknown argument: --version-script(also see https://lists.llvm.org/pipermail/llvm-dev/2018-June/124385.html). Detecting Windows and disablingUSE_MAPhelps, but it would probably be better to get this to work properly:longis used to cast and format function pointers, but on 64-bit Windows that means casting to a smaller integer.Possible patch:
visibility attribute not supported in this configuration; ignoredhidden_aliasbail out whendefined(_WIN32)"fixes" this. Similar changes need to be made in the Ruby generator as well:CL_API_CALLannotations in the generated code, leading to errors a la:stdcallattribute. Naively addingCL_API_CALLto the generated signatures (which picks upstdcallfrom the vendored Khronos headers) fixes the issue listed above, but introduces new mismatches.As I'm not familiar with how the loader works, the
stdcallmismatches is where I gave up. It would be great if somebody familiar with the codebase could patch these up and revive my MSYS2 PR, the groundwork has been laid already.