Installing on Windows

[hadronized]

The install fails with the following error:

phaazon@illusion /tmp
$ cabal update
Downloading the latest package list from hackage.haskell.org

phaazon@illusion /tmp
$ cabal install cuda
Resolving dependencies...
Configuring cuda-0.6.5.1...
Failed to install cuda-0.6.5.1
Build log ( C:\Users\phaazon\AppData\Roaming\cabal\logs\cuda-0.6.5.1.log ):
[1 of 1] Compiling Main             ( C:\Users\phaazon\AppData\Local\Temp\cuda-0.6.5.1-13576\cuda-0.6.5.1\dist\setup\setup.hs, C:\Users\phaazon\AppData\Local\Temp\cuda-0.6.5.1-13576\cuda-0.6.5.1\dist\setup\Main.o )
Linking C:\Users\phaazon\AppData\Local\Temp\cuda-0.6.5.1-13576\cuda-0.6.5.1\dist\setup\setup.exe ...
Configuring cuda-0.6.5.1...
checking for gcc... gcc c:\Program Files\Haskell Platform\2014.2.0.0\mingw\bin\gcc.exe
checking whether the C compiler works... no
configure: error: in `/tmp/cuda-0.6.5.1-13576/cuda-0.6.5.1':
configure: error: C compiler cannot create executables
See `config.log' for more details
cabal.exe: Error: some packages failed to install:
cuda-0.6.5.1 failed during the configure step. The exception was:
ExitFailure 77

[hadronized]

I have both MinGW and MSYS installed as well.

[hadronized]

More details:

configure:2418: gcc c:\Program Files\Haskell Platform\2014.2.0.0\mingw\bin\gcc.exe -V >&5
gcc.exe: error: c:\Program: No such file or directory
gcc.exe: error: Files\Haskell: No such file or directory
gcc.exe: error: Platform\2014.2.0.0\mingw\bin\gcc.exe: No such file or directory
gcc.exe: error: unrecognized option '-V'
gcc.exe: fatal error: no input files

[tmcdonell]

Ah, looks like this is a quoting problem, since the path to your ghc install has spaces in it.

I'm really not a windows user though and don't have a box that I could test on. I believe @mikusp has a working setup though and might be able to help.

Pull requests welcome of course (:

[hadronized]

I’d like to help, but I can’t find the place where such quotes should be put. Maybe in the Setup.hs file?

[hadronized]

I tried to fix that and haven’t found any ways to make it through :(

[tmcdonell]

I think it would be in the configure file. Maybe put all of $withval into quotes, rerun autoconf, and try running cabal configure again?
e.g. https://github.com/tmcdonell/cuda/blob/master/configure.ac#L19

[tmcdonell]

that is change to CC="$withval"

[hadronized]

New errors has spawned:

[tmcdonell]

Can you provide some more information. When exactly does this error occur?

[hadronized]

Just after it checks for the compiler to be there. It still outputs that the compiler doesn’t work, then fails.

[hadronized]

A related issue on SO.

[hadronized]

I found a way to make it compile:

1. Download the package in order to modify it:
   • cd /tmp
   • cabal unpack cuda
   • cd cuda-*
2. Edit the Setup.hs and change this line to wherever the compiler is. On my laptop:
   • [("CC", "/c/MinGW/bin/cc.exe")
3. Verify mpc, gmp and mpfr are installed (see the MinGW package installer otherwise)
4. runhaskell Setup.hs configure does work, now.

[tmcdonell]

1. Is that the compiler that the configure script should have picked up, i.e. first one in your path, what's run if you just type gcc? If not, why do you need to switch to this one?
2. Does this work if you manually tell cabal to use this; e.g.
   • CC=/c/MinGW/bin/cc.exe cabal configure; or
   • cabal configure --with-cc=/c/MinGW/bin/cc.exe (possibly --with-gcc or something else?)

[hadronized]

Yeah, it does work, but I have issue with libs. The single way I’ve found, yet, is to replace the Haskell Platform’s mingw folder by my own, which is filthy and causes crashes :(

[tmcdonell]

Well, that doesn't sound good =
Perhaps the platform has stripped out too much of mingw to be able to link against external libraries? Maybe we should raise the issue there --- I'm not sure if other packages have similar problems.

[hadronized]

God, is everything broken in that package?!

cc @tmcdonell

[tmcdonell]

Well, let's not get snarky now, shall we? From my perspective, windows is the thing that is broken.

We need to tell c2hs to use nvcc as the C pre-processor, because regular cpp doesn't understand nvidia syntax extensions. What is the output of cuda.buildinfo

[hadronized]

Yeah, I changed that in the configure file, and my GPU architecture. Now, the output is:

ghc-options: -optc-Dmingw32_TARGET_OS=1 -optc-Ic:/NVIDIA/CUDAToolkit/include -optl-Lc:/NVIDIA/CUDAToolkit/lib/Win32 
cc-options:  -Dmingw32_TARGET_OS=1  -Ic:/NVIDIA/CUDAToolkit/include  
ld-options:  -Lc:/NVIDIA/CUDAToolkit/lib/Win32  
x-extra-c2hs-options: --cpp=c:/NVIDIA/CUDAToolkit/bin/nvcc --cppopts=-E --cppopts=-arch=sm_52 --cppopts=-Dmingw32_TARGET_OS=1 --cppopts=-m64 
extra-lib-dirs: c:/NVIDIA/CUDAToolkit/lib/Win32
extra-libraries: cuda cudart 
frameworks: 

And error:

c2hs.exe: Error during preprocessing custom header file

[tmcdonell]

er, which file and on what? c2hs (usually) dumps failed files into the root directory, which might help.

[hadronized]

I can’t locate the failed files :/

[hadronized]

I finally have more information! http://lpaste.net/119875 cc @tmcdonell

[tmcdonell]

Ah, so with #26 does it compile for you now? (finally (sorry...))

[hadronized]

Not really, maybe it’s because nvcc is not supposed to be run on .h files :/

[ian-ross]

Maintainer of C2HS here. I've been joining in the "fun". A few things:

1. Running nvcc on header files should be fine, I think.
2. It appears that the CUDA tools on Windows only work with Microsoft Visual Studio -- you need to have the MS C compiler executable cl.exe in your path for nvcc to pick up. There doesn't seem to be any possibility to build CUDA applications with Cygwin or MinGW compilers. You can make this happen by adding some extra nvcc options to the cuda.buildinfo file after configuring -- add something like --cppopts=-compiler-bindir --cppopts="C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin" (although the quoting may not be quite right, since I've only been testing this at the command line and of course it depends on what MS Visual Studio installation you have).
3. When you get C2HS to run nvcc as its preprocessor and nvcc to run the MS C compiler as its preprocessor, you end up with some files that have #line pragmas in them that are different from what you normally get from GCC, and these break the language-c parser that C2HS uses. I have a modified version of this (in my ian-ross/language-c repo) and building a version of C2HS that uses this allows C2HS to parse the files that the MS C compiler and nvcc generate. Unfortunately, at that point things get tricky, because we need to deal with all the MS standard headers, which include various compiler-speciifc types which are different from those used by GCC...

I think at this point I have to give up. I don't know of anyone who's ever tried to use C2HS with the Microsoft C compiler, and I think that it would be very painful to go down that road. Unfortunately, I think that means that it's not going to be possible to build the cuda package on Windows, which is a bit of a shame.

I'd be very happy to be proven wrong, of course!

[tmcdonell]

Well, I think @mainland, @srutownik or @MikeStout managed to get the package installed on Windows. Do any of you have any suggestions? Did you have any trouble using nvcc as the preprocessor?

[tmcdonell]

(Apologies that I am next to useless when it comes to windows)

[hadronized]

I’m not on Windows anymore, back on Archlinux. Though, such an error is a pity :)

[pioole]

@ian-ross
@tmcdonell
@phaazon

Hello.

I'm here with @srutownik, @zgredzik, and @wdanilo still working on this issue, as it is crucial for our case.
Windows OS is one of our target platforms, and in this case failure is not an option. :)

After few days of research I realized that this task overwhelms me, and I probably won't accomplish it myself.
I know that tinkering in Windows doesn't seem to be enjoyable for any of us, but I must ask for your help.

From now on, we would like to provide you any help needed (such as fully configured windows amazon instances, etc.) just to get this task done as soon as possible.
We are considering spending some funds for the help - so we would love to pay you for helping us bring our product to the end!

That's our #1 priority, and your projects will also greatly benefit this way, so please do not abandon us. #mayday
I would be very thankfull for any help from you guys! :)

[ian-ross]

@pioole Trevor can almost certainly comment further on this, but the only successful attempt to get the cuda package working on Windows that I know of was by Geoffrey Mainland, and he last touched it two years ago. You can look on the wip/win32 branch of https://github.com/mainland/cuda to see what he did.

[wdanilo]

@phaazon It is not so desperate - the problem is that we need a huge amount of time to get into the code of c2hs and understand how it is done inside. As you know, it is not an easy task and some people from our company tried doing this, but without any effects - they spend couple of days on this issue. I know that if you know the package and you have contributed to it, you know how it is working - without a proper documentation / introduction to the internal logic, it is just hard to fix the bug.

As @pioole told, we've got fully configured Windows instance on Amazon and we can provide an ssh access to it - would it be suitable for you? Thank you for your help offer - that would be very helpfull for us! :) Of course I would love to collaborate further with both you, @ian-ross and @tmcdonell - we can discuss it and work together on such instances - we can even provide multiple ones for this problem, what do you think about it? :)

[kdmadej]

Well, we've managed to get it running on Windows some time ago (during the last 8-9 months). The thing is we've had other issues with the Windows release for quite a long period of time. While working on those issues we stumbled upon the problems mentioned in this topic.
Either something changed within the "dependency stack" while we were working on our issues or we used to set up our cuda-related environment (on Windows) differently beforehand (which to me seems less likely). We're investigating all the possible causes atm, that's why we're asking for any help we can get.

[ghost]

Hi

As proof it was once possible, see attached png (hope it doesn't
infuriate too much).

Unfortunately I'm not working on Windows, ghc, accelerate, cuda these days.
So I cannot offer help.

Did you try renaming the dlls? As described here (under "Setup dlls"):

https://github.com/AccelerateHS/accelerate/wiki/Installing-Accelerate-CUDA-on-Windows

Since I wrote this, many things have moved on with many packages, so
your milage may vary.

If I were to begin on this again, I would probably start out with a
minimal GHC install on Windows using minGHC

https://github.com/fpco/minghc

and install packages using cabal under a cmd prompt...

Good luck!
Mike

On 29/04/2015 11:50, Piotr Oleksy wrote:

@ian-ross https://github.com/ian-ross
@tmcdonell https://github.com/tmcdonell
@phaazon https://github.com/phaazon

Hello.

I'm here with @srutownik https://github.com/srutownik, @zgredzik
https://github.com/zgredzik, and @wdanilo
https://github.com/wdanilo still working on this issue, as it is
crucial for our case.
Windows OS is one of our target platforms, and in this case failure is
not an option. :)

After few days of research I realized that this task overwhelms me,
and I probably won't accomplish it myself.
I know that tinkering in Windows doesn't seem to be enjoyable for any
of us, but I must ask for your help.

From now on, we would like to provide you any help needed (such as
fully configured windows amazon instances, etc.) just to get this task
done as soon as possible.
We are considering spending some funds for the help - so we would love
to pay you for helping us bring our product to the end!

That's our #1 #1 priority, and
your projects will also greatly benefit this way, so please do not
abandon us. #mayday
I would be very thankfull for any help from you guys! :)

—
Reply to this email directly or view it on GitHub
#25 (comment).

[mwu-tow]

Ugh… difficult. Basically a number of issues bulked into one.

@tmcdonell
I'm trying to understand what is happening here and what needs to be done to finally have cuda package working on Windows. Please forgive me if my questions sound stupid or obvious. I have little experience with cabal, Haskell, CUDA and autotools. I am C++ programmer who uses Windows in everyday work and has a few Haskell-coding colleagues who can't get their software to run on Windows. Ignorant as I am, I hope to at least bring some fresh perspective. ;)
Please help me by explaining why the things are as they are. I went through this thread and collected my observations, ideas and — most important — questions below.

At the moment I see following problems:

1. autoconf is not portable
2. some trickery with copying (symlinking?) files is needed
3. c2hs doesn't work nvcc-preprocessed file <- this is the most serious blocker
4. kernels generated by accelerate-cuda don't compile on Windows (being worked on)

Ad 1
This issues can be worked around by using environment emulators like MSYS. It is annoying (MSYS is horrible) but it is not the first priority. Eventually I believe that configure script should go away, so the package can be just cabal installed without requiring user to use some special environment.

The questions:
a) What data exactly does the configure script leave behind?
b) How is that output is consumed later?
b) If Setup.hs can call autoconf and ./configure, perhaps it could do what configure script does? In a portable way.

Ad 2
The wiki instruction for building on Windows says that some dll's should be renamed:

cp /c/Windows/SysWOW64/nvcuda.dll  /c/CUDA/v5.0/lib/Win32/cuda.dll
cp /c/CUDA/v5.0/bin/cudart32_50_35.dll  /c/CUDA/v5.0/lib/Win32/cudart.dll
cp /c/CUDA/v5.0/bin/cufft32_50_35.dll /c/CUDA/v5.0/lib/cufft.dll

The question: why is this needed? [not that important]

Ad 3
The c2hs tool takes as input a preprocessed C source file. It is non-portable, working only with GCC and not with VS-processed files. Since nvcc emulates behavior of primary compiler on giveen platform (being VS on Windows), on Windows the files preprocessed with nvcc cannot be properly consumed by c2hs. Actually it seems it is not so much c2hs issue, rather the language-c parser it uses.
Possible solutions:

• use some trickery on the nvcc-preprocessed file to strip it from incompatible parts while leaving the parts needed for c2hs — and such "corrected" version of file feed to c2hs. That is — another preprocessor between nvcc and c2hs.
• fix c2hs (or its dependencies) to support nvcc-preprocessed files. The first issue, the #line pragmas were implemented on branch by ian-ross. It is not clear to me what the next issue was. ("various compiler-speciifc types")
• write the input for the c2hs tool by hand
• write the output of c2hs by hand

The questions:
a) Why does nvcc must be used to preprocess file for c2hs and not the gcc?
b) What exactly were the issues with "various compiler-speciifc types" that blocks c2hs from working with nvcc-preprocessed files? @ian-ross
c) How much work it would be to get rid of c2hs and do the thing by hand? Is it feasible at all?

Ad 4
I already did a workaround for this issue, see AccelerateHS/accelerate/issues/234. A proper fix would require support from language-c-quote package — mainland/language-c-quote/issues/52.

[ian-ross]

@mwu-tow To respond to the query about C2HS that you aimed at me: I didn't really make any attempt at all to get C2HS working with MS Visual C++, mostly because by that point I'd already gone quite a ways down the rabbit hole trying to figure out what was going on and just ran out of steam... Hence the rather vague and not very helpful comment about "compiler-specific types".

My personal opinion is that getting C2HS to work with MS VC++ would be a lot of work, primarily because C2HS (or rather the language-c parser on which it depends) was originally targetted only at GCC. You could do it, but it might be more work than it's worth, and you would probably not get much help from other C2HS users because the cuda package is the only one that has this problem (because of the dependence of nvcc on MS VC++). On the other hand, a quick look at the cuda package source reveals that it makes quite extensive use of C2HS, so removing the dependency on C2HS could also be a lot of work. Just taking the Haskell code generated by C2HS (using GCC, say) and replacing all the .chs files with those .hs files might or might not work, but it would definitely make the cuda package much less maintainable -- the whole point of C2HS is that it removes a lot of boilerplate marshalling code that would then be exposed everywhere. That marshalling code is very brittle, and not something you want people having to think about every time they make a change to the cuda package.

I'm not sure I understand what you mean with your third option ("write the input for the C2HS tool by hand"), which leaves the idea of writing a preprocessor to massage the MS VC++ headers before you allow C2HS to ingest them. That would be very feasible if you can identify exactly what features in the MS headers are causing trouble and can come up with a simple (regular expression?) way of fixing them. I fear that that might still be quite difficult though (especially the first part).

As you say: "Ugh… difficult." I don't really have any good advice to offer, I fear, which is why I more or less dropped out of the conversation...

[hadronized]

If I had a Windows key I’d install it in a VM and try to work on that, but currently I only have a linux installed there…

[mwu-tow]

@ian-ross
Thank you for insightful answer, it allowed me to understand situation a little better.

Fixing the language-c parser seems to the most "ideal" solution, however I have no idea how much trouble it is. I'll go over several approaches trying a little of anything, and I'll see where the resistance is weakest. If doing the right thing is possible, I will go for it.

By writing the C2HS input by hand I meant replacing the preprocessed file by some fixed, predetermined content (manually written/copied/generated relevant parts of CUDA headers) that will make C2HS to generate identical (equivalent) output as proper header.

---

I did some experiments and I believe I have a few answers:

1a) configure outputs cuda.buildinfo which contains options for ghc, cc, ld, c2hs, extra library directories and extra labraries to link against. It also outputs config.status. I have no idea if it is needed for anything?

1b) The cuda.buildinfo is consumed by Setup.hs. I believe the getHookedBuildInfo reads the file and it is then used to updatePackageDescription that goes into postConf step.

1c) From what I see getting rid of autoconf altogether should be possible. Still, not the first priority now, if I can get around this now. (I managed to.)

3a) It seems that nvcc must be used because it consumes the -arch=sm_20 flag. Not sure yet how the presence of flag affects preprocessing the files and generating the code.

3c) As ian-ross pointed out, replacing C2HS does not seem feasible. Basically the whole cuda is based on C2HS, removing it means practically rewriting the package from scratch.

I will write again, as I find out more.

[mwu-tow]

@phaazon
I believe you should be able to use an evaluation version od Windows Enterprise edition for 90 days before having to buy a real license. https://www.microsoft.com/en-us/evalcenter/evaluate-windows-8-1-enterprise
If this is still an issue for you, please let me know, we could try providing you with a remote access to one of our machines or sth like this..

Still, I'm not sure if it is feasible to work on cuda package on VM. Wouldn't the lack of actual GPU be an issue when installing NVIDIA CUDA drivers that are needed for cuda package.

[mikusp]

On Linux, lack of NVIDIA GPU is not an issue. I have nvidia-utils and cuda packages installed from my distro repositories and I can install accelerate-cuda just fine.

[mwu-tow]

Going further — the language-c parser fails when parsing standard library headers from Visual Studio. It doesn't know built-in types like __int64 or VS calling convention syntax like __cdecl. I will look what can be done about that.

[ian-ross]

@mwu-tow Right. This is basically what I meant by "compiler-specific types". The language-c parser supports only GCC declarator syntax. In order to make it work with MS VC++, you'd need to add some extra rules to the grammar to deal with the MS VC++ stuff, along with flags to switch it on and off depending on what platform you're on. You said in your first comment that you're a C++ programmer, but one of your Haskelling colleagues could probably make the necessary changes. The language-c parser uses Happy, which is "Bison for Haskell" and isn't too hard to use.

[tmcdonell]

cuda.buildinfo plus the extensive Setup.hs was in particular motivated to pass extra options to c2hs on MacOS X. At the time, I don't think there was a way to do that via the .cabal file (and a lot of the content of Setup.hs is copy-pasted from the cabal library, because the necessary bits weren't exposed.) It also tries to set the right include and library paths, but we could also just expect the user to set that up. This might have changed since last I checked.

I'd suggest seeing if the default pre-processor on windows can be used, rather than setting it to nvcc; the situation may have improved since I tried last time.

Moving away from using C2HS and writing everything manually isn't something I want to think about.

[mwu-tow]

@ian-ross Oh, let the C++ guy have his moment of glory. I know quite much of Haskell (it's not difficult as people tend to say) and I am quickly learning more. :-) I already did some hackery for the language-c-quote, so I should be able to do some small fixes in the language-c parser as well.
The question is, how much of these fixes would be needed. Or, as tmcdonell suggested — perhaps we can get away without making any fixes.

@tmcdonell @phaazon
Do you remember why the nvcc was set to be a preprocessor for C2HS? It was done by phaazon's pull request #26 (commit eecea51), I believe it was meant to make things better on Windows. (given it happened after opening this issue)

[hadronized]

It was for making Windows version compile, yes, but it’s also set for other OS as well. I don’t really remember why we had to set that, I’m looking for logs right now.

[mwu-tow]

@phaazon I tried to check what happens if not nvcc is used as preprocessor, but normal gcc.
If I remove the --cpp option from the configure, it complains about the unknown flag -arch=sm_20. Seemingly, this flag is known only to Nvidia compiler. If I remove the flag as well, it goes a little further and then fails.

I tried this on Linux as well (to get the Windows-specific stuff out of the picture for moment), the output is:

[ec2-user@ip-172-31-13-209 cuda]$ cabal install
Resolving dependencies...
Notice: installing into a sandbox located at
/home/ec2-user/michal/cuda/.cabal-sandbox
Configuring cuda-0.6.5.0...
Building cuda-0.6.5.0...
Failed to install cuda-0.6.5.0
Build log ( /home/ec2-user/michal/cuda/.cabal-sandbox/logs/cuda-0.6.5.0.log ):
Configuring cuda-0.6.5.0...
[snip…]
config.status: creating cuda.buildinfo
Building cuda-0.6.5.0...
Preprocessing library cuda-0.6.5.0...

<command line>:
    Could not find module ‘Foreign.CUDA.Analysis.Device’
    Use -v to see a list of the files searched for.

<command line>:
    Could not find module ‘Foreign.CUDA.Runtime.Device’
    Use -v to see a list of the files searched for.

<command line>:
    Could not find module ‘Foreign.CUDA.Runtime.Error’
    Use -v to see a list of the files searched for.

<command line>:
    Could not find module ‘Foreign.CUDA.Runtime.Event’
    Use -v to see a list of the files searched for.
cabal: Error: some packages failed to install:
cuda-0.6.5.0 failed during the building phase. The exception was:
ExitFailure 1

I am somewhat confused as what these errors mean. I don't know who is searching the modules and what is the relation to switching the preprocessor for C2HS. See the https://gist.github.com/mwu-tow/e66e9e0419a1f5e68b6a for the complete log with -v3.

[mwu-tow]

Okay. I managed to install cuda on Windows. I am working on replicating the process, checking which of the workarounds were actually relevant and so on. Tomorrow I will post a writeup on that.
Note: I have the package installed but that does not necessarily mean it is working. I tried some trivial calls with ghci and it seems working but I have not performed any real computations.

Having a cuda building next I wanted to try accelerate-cuda. However it failed as described in AccelerateHS/accelerate/issues/277
I will gladly accept any ideas on how to proceed with it. [EDIT: already resolved this]

[mwu-tow]

Good news. I managed to install cuda, accelerate-cuda and accelerate-examples. I successfully run the accelerate-nbody example using CUDA.

Summary:
cuda

• I ripped of the configure and manually written the buildinfo. Now I have coded quite solid CUDA toolkit detection mechanisms into Setup.hs itself, so everything will be automatically.
• I removed passing nvcc as the preprocessor, seemingly gcc does just fine. I abandoned any work on language-c parser as it is no longer necessary here.
• cabal install has to be called twice. Between the calls, the dist directory has to be removed. Don't ask me.
• for ghci the cuda and cudart DLL files need to be renamed (probably due to their custom DLL lookup machinery)

accelerate-cuda

• needs language-c-quote with my pretty printer lambda hack — it is necessary to workaround MSVC does not support statement expressions AccelerateHS/accelerate#234

accelerate-examples

• needs to have glut library
• nvcc needs VIsual Studio cl.exe compiler in the PATH
• it usually works, though randomly I get ERROR: CUDA Exception: invalid device context. I have no idea why, I wasn't able to spot any pattern despite spending some time on it.

I used all the mentioned packages from their repos heads.

In the following days I am going to go over all this stuff, clean it up, upload, make it work on other Windows machines and come up with pull requests.

Now, behold:

[hadronized]

Great! Good job!

[wdanilo]

@mwu-tow you are the man! Great job, really! :)

[ian-ross]

@mwu-tow Nice work!

[tmcdonell]

Awesome! Great job! (:

[mwu-tow]

It wouldn't be possible without your support and earlier efforts — thank you!

Now I'm working on a new Setup.hs that discovers CUDA toolkit location. And gives sensible diagnostic messages when failing. If possible, I'd want to get rid of configure.ac altogether. While it would be possible to have both Setup.hs and configure.ac machinery and use one on Windows and the other one elsewhere, it would be just duplicating logic and would cause issues in future (each change would need to be done twice).

I'm still trying to figure out what parts of configure.ac are relevant. When I consider Setup.hs reasonably complete, I'll post a summary of changes relative to the current infrastructure. My observation is that some of the flags and steps are not needed — I'm not sure which are the edge-cases that I have not observed yet and which are historic artifacts that should be removed. I'll probably ask for your help with that later.

If you are impatient, you can check changes in my fork https://github.com/mwu-tow/cuda/tree/windows — the branch Windows should properly install both on Windows and Linux. This is is still not tested enough and work in progress, so some rough edges should be expected. However, I managed to install cuda package on a few machines (both Linux and Windows) without running configure.ac. :)

Notes:

• my Setup.hs discovers CUDA toolkit by checking CUDA_PATH environment variable that is set by CUDA toolkit installer. If the variable is not set, it tries to use lcoation of nvcc if it is visible in PATH.
• things can explode badly if you have in your PATH a gcc different than the one coming with ghc used to compile the package
• for accelerate-cuda to work on Windows, this exact commit of my fork of language-c-quote package is needed mwu-tow/language-c-quote@e670cfd
• some of earlier notes still apply: renaming DLLs for ghci, having VS cl.exe in path to run kernels

[mainland]

My old wip/win32 cuda branch (mainland/cuda@a3c4410e) had most of the machinery needed to get cuda installed under Windows. The one catch was that extra-ghci-libraries was not legal in a cabal file at the time, although I believe that has been changed. It might be worth looking at that old branch; its configure.ac got around the issue of having to rename .dll files.

[mwu-tow]

Yes, I saw that and your work was really a great help. Actually most of what I needed to do was rewriting autoconf.ac to Setup.hs.
Indeed, extra-ghci-libraries can now be passed to cabal and it apparently solves the ghci linker issues. Soon I'll update my Setup.hs to properly generate this field. The nm tools is distributed with ghc, so it can be safely assumed that it is present during installation.

[mwu-tow]

The support for generating extra-ghci-libraries by Setup.hs has been implemented in https://github.com/mwu-tow/cuda/tree/windows
So far I checked my Setup.hs with GHC 7.8.4 on:

• Windows 8.1 + CUDA 6.5
• Windows 10 + CUDA 7.0 (I checked both 32- and 64-bit GHC architecture)
• Linux Fedora 22 + CUDA 6.5

It works as expected. Next I'm going to check the OS X — I saw some entries in configure.ac related to darwin that I still hadn't ported to the new Setup.hs.
When I have it working nad checked on Linux, Windows and OS X, I'm going to submit PR.

[tmcdonell]

This is awesome, thanks! Please be sure to comment the changes, especially all of the tricky parts related to windows, so that I don't accidentally change something in the future and break it (:

[tmcdonell]

I think this can be safely closed now. Thanks again for all involved! (: