我正在尝试将OpenCLRaw绑定设置为可以在Windows上使用它们的点。我已经在github上分叉了OpenCLRaw repo，所以我可以根据需要进行修改。我的分支在这里： https://github.com/dagit/OpenCLRaw
我一直在为我的“FunPtr”分支工作。
我遇到的问题是：我安装了AMD的OpenCL SDK，将他们的Visual Studio特定.lib文件转换为gcc可以处理的文件（.a文件），但ghc似乎无法与之链接。我在OpenCL API中使用的所有内容都有未定义的符号。
我能够构建一个“普通的”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来检查命令行），我仍然无法按摩它进入工作状态。
任何帮助将不胜感激！
答案 0 :(得分：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
这将生成ghc可以正确用于链接的libOpenCL.a，但前提是修改OpenCLRaw以使用stdcall而不是ccall。
现在我已经理解了这个问题，我可以修复OpenCLRaw绑定以在Windows上做正确的事情。
当我使用pexports而不是gendef时，我能够从符号名称中删除@NN，但随后生成的程序开始出现段错误。这是因为找到了符号，但调用约定不正确，可能导致堆栈损坏。
对我来说，主要的教训是你的FFI绑定必须符合你的C库的调用约定。