No se puede vincular OpenCL en Windows con GHC

Question

Estoy tratando de obtener los enlaces OpenCLRaw a un punto donde puedo usarlos en Windows. He bifurcado el repositorio de OpenCLRaw en github para poder hacer las modificaciones necesarias. Mi sucursal está aquí: https://github.com/dagit/OpenCLRaw

He estado trabajando principalmente en mi sucursal "FunPtr".

El problema que tengo es esto: instalé el OpenCL SDK de AMD, convertí su archivo .lib específico de Visual Studio a un archivo que gcc puede manejar (un archivo), pero ghc parece que no puede vincularlo . Obtengo símbolos indefinidos para todo lo que uso en la API de OpenCL.

Pude crear un programa C "trivial" y vincularlo usando el archivo .a que generé y gcc de mingw (no de la instalación de Haskell). Estoy usando el último lanzamiento de Windows de la plataforma Haskell.

Estos son los pasos que utiliza para generar el archivo .a: http://forums.amd.com/forum/messageview.cfm?catid=390&threadid=138890

I utilizado los comandos en el script de ejemplo (por ejemplo, gendef y dlltool). Intenté usar todo 32 bits todo lo posible, ya que sé que GHC querrá que todo sea de 32 bits, así que no creo que sea un problema de 32 bits frente a uno de 64 bits.

¿Alguien sabe si hay algo diferente sobre la invocación de gcc bajo ghc en lugar de gcc que obtengo de mingw?

También he jugado con la línea de comando ghc (utilicé el comando cabal-dev --verbose = 3 para inspeccionar la línea de comandos) y todavía no puedo masajearlo en un estado funcional.

¡Cualquier ayuda sería apreciada!

Answer 1

OpenCL utiliza la convención stdcall, pero OpenCLRaw está usando ccall. Esto crea varios problemas. El principal es que el enlazador quiere que los símbolos del nombre de la función terminen en @NN, donde NN depende de la función.

Como resultado, la forma correcta para generar libOpenCL.a es la siguiente (de una concha MinGW):

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

Esto generará libOpenCL.a que GHC puede usar correctamente para ligarse, pero sólo si OpenCLRaw se modifica para usar stdcall en lugar de ccall.

Ahora que entiendo el problema, puedo arreglar los enlaces OpenCLRaw para hacer lo correcto en Windows.

Cuando utilicé pexports en lugar de gendef, pude eliminar @NN de los nombres de los símbolos, pero luego el programa resultante comenzó a segfault. Esto se debe a que se encontró el símbolo, pero la convención de llamadas era incorrecta, lo que probablemente daría lugar a pilas dañadas.

La principal lección para mí es que su enlace FFI debe coincidir con la convención de llamadas de su biblioteca C.