Comments (57)
I have both MinGW and MSYS installed as well.
from cuda.
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
from cuda.
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 (:
from cuda.
I’d like to help, but I can’t find the place where such quotes should be put. Maybe in the Setup.hs
file?
from cuda.
I tried to fix that and haven’t found any ways to make it through :(
from cuda.
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
from cuda.
that is change to CC="$withval"
from cuda.
New errors has spawned:
from cuda.
Can you provide some more information. When exactly does this error occur?
from cuda.
Just after it checks for the compiler to be there. It still outputs that the compiler doesn’t work, then fails.
from cuda.
from cuda.
I found a way to make it compile:
- Download the package in order to modify it:
cd /tmp
cabal unpack cuda
cd cuda-*
- Edit the
Setup.hs
and change this line to wherever the compiler is. On my laptop:[("CC", "/c/MinGW/bin/cc.exe")
- Verify mpc, gmp and mpfr are installed (see the MinGW package installer otherwise)
runhaskell Setup.hs configure
does work, now.
from cuda.
- 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? - Does this work if you manually tell cabal to use this; e.g.
CC=/c/MinGW/bin/cc.exe cabal configure
; orcabal configure --with-cc=/c/MinGW/bin/cc.exe
(possibly--with-gcc
or something else?)
from cuda.
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 :(
from cuda.
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.
from cuda.
God, is everything broken in that package?!
cc @tmcdonell
from cuda.
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
from cuda.
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
from cuda.
er, which file and on what? c2hs
(usually) dumps failed files into the root directory, which might help.
from cuda.
I can’t locate the failed files :/
from cuda.
I finally have more information! http://lpaste.net/119875 cc @tmcdonell
from cuda.
Ah, so with #26 does it compile for you now? (finally (sorry...))
from cuda.
Not really, maybe it’s because nvcc
is not supposed to be run on .h
files :/
from cuda.
Maintainer of C2HS here. I've been joining in the "fun". A few things:
- Running
nvcc
on header files should be fine, I think. - 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 fornvcc
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 extranvcc
options to thecuda.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). - When you get C2HS to run
nvcc
as its preprocessor andnvcc
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 thelanguage-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 andnvcc
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!
from cuda.
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?
from cuda.
(Apologies that I am next to useless when it comes to windows)
from cuda.
I’m not on Windows anymore, back on Archlinux. Though, such an error is a pity :)
from cuda.
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! :)
from cuda.
@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.
from cuda.
I’d love to help, even though that sounds a bit desperate. I don’t have any windows on my machine, though.
from cuda.
@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? :)
from cuda.
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.
from cuda.
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/phaazonHello.
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).
from cuda.
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:
- autoconf is not portable
- some trickery with copying (symlinking?) files is needed
c2hs
doesn't worknvcc
-preprocessed file <- this is the most serious blocker- 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 install
ed 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 forc2hs
— and such "corrected" version of file feed toc2hs
. That is — another preprocessor betweennvcc
andc2hs
. - fix
c2hs
(or its dependencies) to supportnvcc
-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.
from cuda.
@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...
from cuda.
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…
from cuda.
@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.
from cuda.
@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.
from cuda.
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.
from cuda.
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.
from cuda.
@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.
from cuda.
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.
from cuda.
@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)
from cuda.
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.
from cuda.
@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.
from cuda.
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]
from cuda.
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 intoSetup.hs
itself, so everything will be automatically. - I removed passing
nvcc
as the preprocessor, seeminglygcc
does just fine. I abandoned any work onlanguage-c
parser as it is no longer necessary here. cabal install
has to be called twice. Between the calls, thedist
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 AccelerateHS/accelerate/issues/234
accelerate-examples
- needs to have glut library
- nvcc needs VIsual Studio
cl.exe
compiler in thePATH
- 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.
from cuda.
Great! Good job!
from cuda.
@mwu-tow you are the man! Great job, really! :)
from cuda.
@mwu-tow Nice work!
from cuda.
Awesome! Great job! (:
from cuda.
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 checkingCUDA_PATH
environment variable that is set by CUDA toolkit installer. If the variable is not set, it tries to use lcoation ofnvcc
if it is visible inPATH
. - things can explode badly if you have in your
PATH
agcc
different than the one coming withghc
used to compile the package - for
accelerate-cuda
to work on Windows, this exact commit of my fork oflanguage-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
from cuda.
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.
from cuda.
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.
from cuda.
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.
from cuda.
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 (:
from cuda.
I think this can be safely closed now. Thanks again for all involved! (:
from cuda.
Related Issues (20)
- Build fails with library profiling HOT 4
- Compilation fails for CUDA-8 [was: ghc 7.10.3 fail to install] HOT 2
- On Windows, the Cabal installer is looking in the wrong place. HOT 5
- Problem with module `Foreign.CUDA.Path' when installing on Windows 8.1 with CUDA-8.0 HOT 38
- Issues with dynamic parallelism? HOT 3
- GHCi only works with Stack with a custom cabal.buildinfo file. HOT 1
- Structure of nvidia-cuda-toolkit seems to have changed in Ubuntu 18.04 HOT 3
- Driver failure on AWS p3.2xlarge instance HOT 18
- Build failure in cuda-0.10.0.0 HOT 3
- Won't compile on Arch Linux HOT 3
- Ubuntu 16.04 + nvidia-cuda-toolkit "Found CUDA toolkit at: /usr" but 'Could not find path: ["/usr/lib64"]' HOT 7
- package revision to restrict Cabal to <3.0 HOT 1
- Compile issues for Cabal 2? HOT 2
- Cannot find a definition for `cuDevicePrimaryCtxRelease' in the header file. HOT 3
- CUDA 11.3 compatibility HOT 4
- rpath linking to cuda toolkit HOT 2
- This Library isn't Compatible with Windows HOT 4
- Porting to CUDA 12.2. HOT 1
- Compilation broken on windows
- Unknown CUDA device compute capability: 8.7 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cuda.