[Haskell-cafe] install cuda

[Geoffrey Mainland]

On 03/31/2013 05:55 PM, Peter Caspers wrote:
>>
>> The environment variable should probably be LIBRARY_PATH; I use a
semicolon as separator.
>> See also LD_LIBRARY_PATH vs LIBRARY_PATH[0].
>>
>
> yes, it's LIBRARY_PATH. The x64 version of cuda.lib is not recognized
> at all (same error message as if the file was not existent). The Win32
> version "works", but results in
>
> configure:3627: c:\HaskellPlatform\2012.4.0.0\mingw\bin\gcc.exe -o
conftest.exe -Wl,--hash-size=31 -Wl,--reduce-memory-overheads
-I/c/CUDA/NVIDIA_GPU_Computing_Toolkit/CUDA/v4.1/include
-L/c/CUDA/NVIDIA_GPU_Computing_Toolkit/CUDA/v4.1/lib  conftest.c
-lcuda   >&5
> C:\Users\Peter\AppData\Local\Temp\ccOwCQ6n.o:conftest.c:(.text+0xc):
undefined reference to `cuDriverGetVersion'
> collect2: ld returned 1 exit status
>
> I ran nm on cuda.lib and got the entry
>
> nvcuda.dll:
> 00000000 I .idata$4
> 00000000 I .idata$5
> 00000000 I .idata$6
> 00000000 T .text
>          U _IMPORT_DESCRIPTOR_nvcuda
> 00000000 I _imp__cuDriverGetVersion at 4
> 00000000 T cuDriverGetVersion at 4
>
> this looks ok so far. Running nm on the x64 version of the lib file
> results in rubbish output (consistent with the observation above).

You're using a version of GHC that targets 32-bit x86, so the 64-bit
library is not going to do you any good. cuDriverGetVersion at 4 is the
stdcall-mangled version of cuDriverGetVersion. The CUDA headers (at
least in the 5.0 toolkit) do not properly declare all CUDA functions as
stdcall under gcc, even though they are. This is why you get an
undefined reference---gcc see cuDriverGetVersion' declared ccall in the
header, so it looks for the wrong symbol. I would guess that the 4.1
toolkit has this same problem the same.

In general, there is no support for using the CUDA SDK with the mingw
tools. I hacked around this enough to get it to work for the driver API,
but you have to use my fork.

> I understand that LD_LIBRARY_PATH is used to look up to dll when
> running the program (is that correct?). However we are not at this
> point yet, are we, since the error occurs on the gcc invocation ?
>
>> Try my fork:
>>
>> https://github.com/mainland/cuda
>>
>> In particular, read WINDOWS.md.
>
> I also read Geoffreys WINDOWS.md and understood that configuring dll
> names are only necessary when using ghci, not for compiled programs
> (nothing to do for this case ?) and in particular not for installing
> the package ?

There's more to it than reading my WINDOWS.md. If you want to build the
cuda package at all, you also need to use my fork.

> Actually the dll is not named nvcuda.dll as indicated in the nm
> output, but rather cudart32_41_28.dll I suppose and this file is
> located in the bin subfolder. I should set LD_LIBRARY_PATH to the bin
> folder, yes ? Should I configure this dll name for package
> installation already (i.e. in addition to what is mentioned in
> WINDOWS.md) ? If yes, how ?

There are two dlls you need. nvcuda.dll corresponds to libcuda on Linux,
and its .lib file on Windows is cuda.lib. cudart32_41_28.dll corresponds
to libcudart on Linux, and its .lib file on Windows is cudart.lib. You
will need them both.

I was able to install the cuda package under 32-bit GHC 7.4.2 using the
5.0 SDK and use it from within ghci. This required using my fork of the
cuda repo and following the instructions in my WINDOWS.md. Make sure
nvcc is in your path (the CUDA installer should have made this so) and
try 'cabal configure'.

LD_LIBRARY_PATH is used on most UNIX flavors. I don't believe it does
anything in Windows. You will instead need to modify your Path
environment variable from the System Settings->Advanced System Settings
control panel.

Geoff