我试图让OpenCLRaw绑定到一个点，我可以在Windows上使用它们。 我已经在Github上分配了OpenCLRaw仓库，所以我可以根据需要进行修改。 我的分支在这里： https ： //github.com/dagit/OpenCLRaw
我一直主要从我的“FunPtr”分支开始工作。
我遇到的问题是这样的：我安装了AMD的OpenCL SDK，将他们的Visual Studio特定的.lib文件转换为gcc可以处理的文件（.a文件），但ghc似乎无法链接。 我在OpenCL API中使用了一些未定义的符号。
我能够构build一个“简单的”C程序，并使用我生成的.a文件和来自mingw的gcc（而不是从Haskell安装）链接它。 我正在使用Haskell平台的最新Windows版本。
这些是我用来生成.a文件的步骤： http ://forums.amd.com/forum/messageview.cfm?catid=390&threadid= 138890
我在示例脚本中使用了命令（例如，gendef和dlltool）。 我尽量使用32位的一切尽可能，因为我知道GHC会希望一切都是32位，所以我不认为这是一个32位与64位的问题。
有没有人知道是否有什么不同的ghc下调用gcc而不是我从mingw获得的gcc？
我也玩过ghc命令行（我使用cabal-dev –verbose = 3来检查命令行），我仍然无法将其按摩到工作状态。
任何帮助，将不胜感激！
OpenCL使用stdcall约定，但OpenCLRaw使用ccall 。 这造成了几个问题。 主要的一点是，链接器想要函数名称符号以@NN结尾，其中NN取决于函数。
事实证明，生成libOpenCL.a的正确方法如下（来自mingw shell）：
cp /c/Windows/System32/OpenCL.dll . gendef OpenCL.dll dlltool -l libOpenCL.a -d OpenCL.def -k -A
这将生成libOpenCL.a ghc可以正确使用链接，但只有OpenCLRaw修改为使用stdcall而不是ccall。
现在我明白了这个问题，我可以修复OpenCLRaw绑定，在Windows上做正确的事情。
当我使用pexports而不是gendef时，我能够从符号名称中移除@NN，但是随后生成的程序开始出现段错误。 这是因为符号被找到，但调用约定是不正确的，可能导致堆栈损坏。
对我来说主要的教训是你的FFI绑定必须符合你的C库的调用约定。