Can't link OpenCL on Windows with GHC
OpenCL uses the stdcall convention, but OpenCLRaw is using ccall. This creates several issues. The main one being that the linker wants the function name symbols to end in @NN where NN depends on the function.
As it turns out, the correct way to generate libOpenCL.a is as follows (from a mingw shell):
cp /c/Windows/System32/OpenCL.dll .gendef OpenCL.dlldlltool -l libOpenCL.a -d OpenCL.def -k -AThis will generate libOpenCL.a that ghc can correctly use for linking, but only if OpenCLRaw is modified to use stdcall instead of ccall.
Now that I understand the problem I can fix the OpenCLRaw bindings to do the right thing on Windows.
When I used pexports instead of gendef, I was able to remove the @NN from the symbol names, but then the resulting program started to segfault. This is because the symbol was found but the calling convention was incorrect, probably leading to corrupted stacks.
The main lesson for me is that your FFI binding must match your C library's calling convention.