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@4 00000000 T cuDriverGetVersion@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@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