Не могу связать OpenCL в Windows с GHC - PullRequest
Новая
       21

Не могу связать OpenCL в Windows с GHC

11 голосов
/ 12 сентября 2011

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

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

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

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

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

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

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

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

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

1 Ответ

3 голосов
/ 13 сентября 2011

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

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

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.

...