Не могу связаться с OpenCL на окна с помощью GHC

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

Я в основном работал из своей ветви "FunPtr".

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

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

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

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

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

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

Любая помощь был бы признателен!

1 11
haskell windows linker opencl

1 ответ:

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

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

cp /c/Windows/System32/OpenCL.dll .
gendef OpenCL.dll
dlltool -l libOpenCL.a -d OpenCL.def -k -A

Это создаст libOpenCL.а что с GHC может правильно использовать для связывания, но только если OpenCLRaw модифицирован для использования нарушением соглашения о стандартном вместо бпризовут.

Теперь, когда я понял проблему, я могу исправить привязки OpenCLRaw, чтобы сделать правильную вещь в Windows.

Когда я использовал pexports вместо gendef, я смог удалить @NN из имен символов,но затем получившаяся программа начала сегментировать. Это происходит потому, что символ был найден, но соглашение о вызове было неверным, что, вероятно, привело к повреждению стеков.

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

3