Невозможно связать OpenCL с Windows с GHC

Я пытаюсь получить привязки OpenCLRaw к точке, где я могу использовать их в окнах. Я разветкил репозиторий OpenCLRaw на github, чтобы внести изменения по мере необходимости. Мой филиал находится здесь: https://github.com/dagit/OpenCLRaw

В основном я работал над своей веткой "FunPtr".

Проблема, с которой я столкнулась, заключается в следующем: я установил AMD OpenCL SDK, преобразовал свой .lib файл в Visual Studio в файл, который gcc может обрабатывать (.a файл), но ghc, похоже, не может ссылаться на него. Я получаю символы undefined для всего, что я использую в API OpenCL.

Мне удалось создать "тривиальную" программу на C и связать ее с помощью файла .a, который я сгенерировал, и gcc из mingw (а не из установки Haskell). Я использую последнюю версию Windows платформы Haskell.

Это шаги, которые я использовал для создания файла .a: http://forums.amd.com/forum/messageview.cfm?catid=390&threadid=138890

Я использовал команды в примере script (например, gendef и dlltool). Я старался использовать все 32 бита как можно больше, так как я знаю, что GHC хочет, чтобы все было 32 бит, поэтому я не думаю, что это проблема с 32-битной версией и 64-разрядной версией.

Кто-нибудь знает, есть ли что-то другое в вызове gcc под ghc вместо gcc, который я получаю из mingw?

Я также играл с командной строкой ghc (я использовал cabal-dev --verbose = 3 для проверки командной строки), и я все еще не могу массировать его в рабочее состояние.

Любая помощь будет оценена!

Ответ 1

OpenCL использует соглашение stdcall, но OpenCLRaw использует ccall. Это создает несколько проблем. Главное, что линкер хочет, чтобы символы имени функции заканчивались в @NN, где NN зависит от функции.

Как выясняется, правильный способ генерации libOpenCL.a выглядит следующим образом (из командной оболочки):

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 из имен символов, но затем результирующая программа начала segfault. Это связано с тем, что символ был найден, но вызывающее соглашение было неправильным, что, вероятно, привело к поврежденным стекам.

Главный урок для меня заключается в том, что ваша привязка FFI должна соответствовать вашему вызову на использование библиотеки C.