Visual Studio C++ 2010 troubles

[Unsure23]

Hi guys, I need help figuring out what I misconfigured to get Visual Studio C++ 2010 to use emscripten.

I followed the instructions at: https://github.com/kripken/emscripten/wiki/Using-Emscripten-on-Windows#tips-for-using-emscripten-from-the-visual-studio-2010-ide, and I can get my simple hello world program to work via the command prompt but I can't get it to run in Visual Studio.

1>------ Rebuild All started: Project: WebGL, Configuration: Debug Emscripten ------
1>  main.cpp
1>  DEBUG    root: invocation: C:\Programs\Emscripten\\emcc @C:\Users\Brian\AppData\Local\Temp\tmpa20ec652f643447fb7cf606d2c2736dd.rsp
1>  INFO     root: (Emscripten: Running sanity checks)
1>  DEBUG    root: compiling to bitcode
1>  DEBUG    root: compiling source file: Code/main.cpp
1>  DEBUG    root: running:C:\Programs\mingw64\bin\clang++ -DEMSCRIPTEN -D__STDC__ -MD -MF Emscripten/Debug/main.d -x c++ -std=c++03 -m32 -U__i386__ -U__i386 -Ui386 -U__SSE__ -U__SSE_MATH__ -U__SSE2__ -U__SSE2_MATH__ -U__MMX__ -DEMSCRIPTEN -D__EMSCRIPTEN__ -U__STRICT_ANSI__ -D__IEEE_LITTLE_ENDIAN -fno-math-errno -fno-threadsafe-statics -target le32-unknown-nacl -U__native_client__ -U__pnacl__ -U__ELF__ -nostdinc -nostdinc++ -Xclang -nobuiltininc -Xclang -nostdsysteminc -Xclang -isystemC:\Programs\Emscripten\system\local\include -Xclang -isystemC:\Programs\Emscripten\system\include\libcxx -Xclang -isystemC:\Programs\Emscripten\system\include -Xclang -isystemC:\Programs\Emscripten\system\include\emscripten -Xclang -isystemC:\Programs\Emscripten\system\include\bsd -Xclang -isystemC:\Programs\Emscripten\system\include\libc -Xclang -isystemC:\Programs\Emscripten\system\include\gfx -Xclang -isystemC:\Programs\Emscripten\system\include\net -Xclang -isystemC:\Programs\Emscripten\system\include\SDL -U__APPLE__ -U__linux__ -emit-llvm -c Code/main.cpp -o C:\Windows\Temp\tmpyarisk\main_0.o
1>clang++ : warning : argument unused during compilation: '-nostdinc++'
1>  DEBUG    root: invocation: C:\Programs\Emscripten\\emcc @C:\Users\Brian\AppData\Local\Temp\tmp05f9b0661470469aa0b0e53485f6c27f.rsp
1>GCCLINK : error root: 
1>  subprocess.Popen(args=C:\Programs\mingw64\bin\clang++ -v) failed! Exception [Error 6] The handle is invalid
1>  
1>GCCLINK : warning root: Could not verify LLVM version: [Error 6] The handle is invalid
1>  INFO     root: (Emscripten: Running sanity checks)
1>  DEBUG    root: compiling to bitcode
1>  DEBUG    root: copying bitcode file: Emscripten/Debug/main.o
1>  DEBUG    root: will generate JavaScript
1>GCCLINK : error root: 
1>  subprocess.Popen(args=C:\Programs\mingw64\bin\llvm-nm C:\Windows\Temp\tmpswe3hy\main_0.o) failed! Exception [Error 6] The handle is invalid
1>  
1>  Traceback (most recent call last):
1>    File "C:\Programs\Emscripten\\emcc", line 1341, in 
1>      symbolses = map(lambda temp_file: shared.Building.llvm_nm(temp_file), temp_files)
1>    File "C:\Programs\Emscripten\\emcc", line 1341, in 
1>      symbolses = map(lambda temp_file: shared.Building.llvm_nm(temp_file), temp_files)
1>    File "C:\Programs\Emscripten\tools\shared.py", line 1046, in llvm_nm
1>      output = Popen([LLVM_NM, filename], stdout=stdout, stderr=stderr).communicate()[0]
1>    File "C:\Programs\Emscripten\tools\shared.py", line 51, in __init__
1>      raise e
1>  WindowsError: [Error 6] The handle is invalid
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

It looks like it makes the object file at C:\Windows\Temp\tmpyarisk\main_0.o but python is looking for the file at C:\Windows\Temp\tmpswe3hy\main_0.o. I've tried this with EM_SAVE_DIR=1 and EMCC_DEBUG=1 which should make it store the object file at C:\Windows\Temp\emscripten_temp but it's not. Is there a step I missed?

[juj]

Recently, people have reported that 64-bit toolchain will not work for VS2010. Try replacing python, node and clang with 32-bit versions instead, and possibly removing the 64-bit MinGW, as it should not be needed with the VS2010 integration.

See juj/vs-tool#15 for more information.

[juj]

Oh, and for the question, I'm thinking that tmp_xxxxx difference is a red herring - I assume it is actually two different runs of the tool that have generated two different temp paths, and there should not be an issue in that front.

[juj]

Does this issue still persist?

[Unsure23]

Sorry for the delay, I got buried in other work. I reinstalled everything (32 bit) and I compiled LLVM myself and it works, so I'm not sure if I had a 64bit program in there somewhere or if I mis-compiled LLVM or what. Knowing myself, it was probably something simple I did wrong or missed something or something.