haskell - Kan ikke linke OpenCL på Windows med GHC

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg forsøger at få OpenCLRaw-bindingerne til et punkt, hvor jeg kan bruge dem på Windows. Jeg har forked OpenCLRaw-repo på github, så jeg kan foretage ændringer efter behov. Min gren er her:
https://github.com/dagit/OpenCLRaw[5]


Jeg har mest arbejdet ud af min 'FunPtr' afdeling.


Problemet jeg har er dette: Jeg installerede AMD s OpenCL SDK, konverterede deres Visual Studio specifikke .lib fil til en fil, som gcc kan håndtere (.a fil), men ghc kan ikke synes at linke med det. få udefinerede symboler til alt, hvad jeg bruger i OpenCL API.


Jeg kunne bygge et 'trivielt' C-program og linke det ved hjælp af .a-filen, som jeg genererede og gcc fra mingw (ikke fra Haskell-installationen). Jeg bruger den nyeste Windows-udgave af Haskell-platformen.


Dette er de trin, jeg brugte til at generere .a-filen:
http://forums.amd.com/forum/messageview.cfm?catid=390u0026amp;threadid=138890[6]


Jeg brugte kommandoerne i eksemplet script (fx gendef og dlltool). Jeg har forsøgt at bruge 32bit alt så meget som muligt, da jeg ved, at GHC vil have alt til at være 32bit, så jeg tror ikke det er et 32bit versus 64bit problem.


Er der nogen der ved, om der er noget andet om at påberåbe gcc under ghc i stedet for gcc, som jeg får fra mingw?


Jeg har også spillet med ghc kommandolinjen (jeg brugte cabal-dev --verbose=3 for at inspicere kommandolinjen) og jeg kan stadig ikke massere den til en arbejdsstatus.


Enhver hjælp ville blive værdsat!

Bedste reference


OpenCL bruger stdcall-konventionen, men OpenCLRaw bruger ccall. Dette skaber flere problemer. Den primære er at linkeren vil have funktionsnavnet symboler til at slutte i @NN hvor NN afhænger af funktionen. [7]


Som det viser sig, er den korrekte måde at generere libOpenCL.a på som følger (fra en mingw shell):


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


Dette vil generere libOpenCL.a, som ghc kan bruges korrekt til at forbinde, men kun hvis OpenCLRaw er ændret til at bruge stdcall i stedet for ccall.


Nu hvor jeg forstår problemet, kan jeg reparere OpenCLRaw bindingerne til at gøre det rigtige på Windows.


Da jeg brugte pexports i stedet for gendef, kunne jeg fjerne @NN fra symbolnavnet, men så begyndte det resulterende program sigfault. Dette skyldes, at symbolet blev fundet, men kaldkonventionen var forkert, hvilket sandsynligvis førte til beskadigede stakke.


Den vigtigste lektion for mig er, at din FFI-binding skal matche din C-bibliotekets kaldekonvention.