# make mathematica recognize CCompiler and compile CUDA code on remote Windows machine

I have set up a Mathematica remote kernel on a Windows 7 64 bit machine, which has Microsoft Visual Studio 2010 installed. When I start Mathematica on the windows machine Mathematica recognizes the C-Compiler without any problems and I can compile code using Compile as expected. But when I connect to the same machine via remote kernel, Mathematica does not find any C-Compiler, i.e.

Needs["CCompilerDriver"]; CCompilers[]


yields only an empty list {}. When using Mathematica on the same machine locally the MS C-Compiler is listed when using CCompilers[]. How can I make Mathematica recognize my local C-Compilers when connecting via remote kernel connection?

Furthermore how can I compile CUDA-Code via the remote kernel connection, see below for the errors I get, when the MS C-Compiler is working?

Additional Information: I do connect to the windows machine from a Mac using Wolfram-SSH. I am running Cygwin OpenSSH on the remote windows machine. The setup seems to work fine otherwise. I tested remote connections to computers running Mac OS and Ubuntu Linux and I did not have any trouble with C-Compilers there.

Update (CCompiler working, still no luck with compiling CUDA code):

I have been able to get the MS C-Compiler working by explicitly setting

$CCompiler = {"Name" -> "Visual Studio", "Compiler" -> CCompilerDriverVisualStudioCompilerVisualStudioCompiler, "CompilerInstallation" -> "C:\\Program Files (x86)\\Microsoft Visual Studio 10.0", "CompilerName" -> Automatic}  But my next step is to get the NVCC compiler to work in order to be able to compile CUDA code using CUDAFuncitonLoad. Unfortunately my intended target Windows-x86-64, which corresponds to my $SystemID is not recognized as a valid target option any more (it is though when running any nvcc compilation locally on the remote machine). This can be seen by executing the following example code:

cudaString = "__global__ void addTwo(mint * A, mint length) {
int index = threadIdx.x + blockIdx.x*blockDim.x;
if (index < length)
A[index] += 2;
}"

res = CreateExecutable[cudaString, "addTwo", "Compiler" -> NVCCCompiler,
"CreatePTX" -> True, "CompileOptions" -> "-v",
"ShellCommandFunction" -> Print, "TargetDirectory" -> "C:\\temp",
"WorkingDirectory" -> "C:\\temp\\Working",
"Defines" -> {"mint" -> "int"}]
(*CreateExecutable::target: Target system specification "TargetSystemID" -> Windows-x86-64 is not available for NVIDIA CUDA Compiler installation "C:\Users\Wizard\AppData\ Roaming\Mathematica\Paclets\Repository\CUDAResources-Win64-9.0.2.0\CUDAToolkit\bin\*)


Manually adjusting the compiler paths does not help in this case, the following command gives me the same error as mentioned above:

res = CreateExecutable[cudaString, "addTwo", "Compiler" -> NVCCCompiler,
"CreatePTX" -> True, "CompileOptions" -> "-v",
"ShellCommandFunction" -> Print, "TargetDirectory" -> "C:\\temp",
"WorkingDirectory" -> "C:\\temp\\Working",
"Defines" -> {"mint" -> "int"},
"CompilerInstallation" ->
"C:\\Users\\Wizard\\AppData\\Roaming\\Mathematica\\Paclets\\\
Repository\\CUDAResources-Win64-9.0.2.0\\CUDAToolkit\\bin\\",
"XCompilerInstallation" ->
"C:\\Program Files (x86)\\Microsoft Visual Studio 10.0",
"TargetSystemID" -> $SystemID]  Update 2 (Changing "TargetSystemID"): As you can see in the code snippet above "ShellCommandFunction" -> Print has been set, but I did not get any output except the error I mentioned above, i.e. CreateExecutable::target: Target system specification "TargetSystemID" -> Windows-x86-64 is not available for NVIDIA CUDA Compiler installation "C:\Users\Wizard\AppData\ Roaming\Mathematica\Paclets\Repository\CUDAResources-Win64-9.0.2.0\CUDAToolkit\bin\ When setting the "TargetSystemID"->"Windows" (which is the wrong target) in the CreateExecutable-call above, mathematica asks for a correct "XCompilerInstallation"-path, which is a good sign. When I manually supply the path (as you can see in the call to CreateExecutable below) I get more information from the "ShellCommandFunction", which I currently cannot make sense of (except that nvcc seems to be called in the right way): cudaString = "__global__ void addTwo(mint * A, mint length) { int index = threadIdx.x + blockIdx.x*blockDim.x; if (index < length) A[index] += 2; }"; res = CreateExecutable[cudaString, "addTwo", "Compiler" -> NVCCCompiler, "CreatePTX" -> True, "CompileOptions" -> "-v", "ShellCommandFunction" -> Print, "TargetDirectory" -> "C:\\temp", "WorkingDirectory" -> "C:\\temp\\Working", "Defines" -> {"mint" -> "int"}, "CompilerInstallation" -> "C:\\Users\\Wizard\\AppData\\Roaming\\Mathematica\\Paclets\\\ Repository\\CUDAResources-Win64-9.0.2.0\\CUDAToolkit\\bin\\", "XCompilerInstallation" -> "C:\\Program Files (x86)\\Microsoft Visual Studio 10.0", "TargetSystemID" -> "Windows"]  Which gives me the output from the "ShellCommandFunction": call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 "C:\Users\Wizard\AppData\Roaming\Mathematica\Paclets\Repository\CUDAResources-Win64-9.0.2.0\CUDAToolkit\bin\nvcc.exe" -ptx -m32 --compiler-bindir "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin" -arch=sm_10 -O3 -v -Dmint=int -o "C:\temp\Working\addTwo.ptx" "C:\temp\Working\addTwo.cu" But also the following error messages (which I find confusing, because the path mathematica complains it cannot open is never created): OpenWrite::noopen: "Cannot open !(\"C:\\Windows\\m-1937a361-0128-49fa-8ead-8640028d2166\")." General::stream:$Failed is not a string, InputStream[ ], or OutputStream[ ]. ... and more errors that follow from the initial one

-
I have tried your example with the following setting: FrontEnd runs on MacOSX and I connect remotely to a Linux box with installed Cuda. Both, the compilation to "C" and the creation of the cuda code, works without problems. Can you add more details on your exact setting? What is your OS, how exactly did you configure the remote kernel? If I should make an educated guess, then I would say your environment variables are not set up correctly when you connect remotely. –  halirutan May 1 '14 at 22:39
Sorry, I have seen that you have already included all this information. I guess I must have missed it the first time. Now I'm pretty sure that it is a PATH and environment problem. When I compile my (other) code for Windows, I specifically have to use the console which comes with VS (or with the Intel Compiler) because there are all paths set up correctly. With the standard cygwin, it never worked from the beginning and I had to adjust everything. The first thing I would try is the following: –  halirutan May 1 '14 at 22:42
With the "ShellCommandFunction" set to Print, you see the exact command which is used for compilation. Use this to compile a small example by manually logging in remotely over ssh and see if it works. Then, have a look at the dev-console of VS. Usually they use a batch script to set up the paths correctly. The specific settings there (here comes the important part!) decide on my machine whether or not I'm compiling for Win 32bit or Win 64bit. Maybe this is the reason for your \$SystemID error. –  halirutan May 1 '14 at 22:53
@halirutan: Thanks for your suggestions. Unfortunately setting "ShellCommandFunction"->Print does not give any information unless I change the "TargetSystemID" from "Windows-x86-64" (which is the correct one for my system) to "Windows". For the output see my edit of the post above. –  Wizard May 2 '14 at 9:13
Would you consider to join the Mathematica Chat? I guess I'm online there in about 20min. –  halirutan May 2 '14 at 10:33

For the record, if someone runs into a similar issue: One way of tracking down compilation errors is to use "ShellCommandFunction":>Print in the CreateExecutable` call to see the exact compilation command Mathematica is using. Use this to run the compilation manually in a (cygwin-)terminal to see whether it works there. The reason why I suggest this is, that I had situations where the compilation worked in the terminal, but it doesn't inside Mathematica just because the shell had additional environment variables set.