Repository navigation
Visual Studio C++ 2010 troubles #1360
Description
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?
Activity
juj commentedon Aug 17, 2013
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 commentedon Aug 17, 2013
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 commentedon Sep 4, 2013
Does this issue still persist?
Unsure23 commentedon Oct 10, 2013
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.
Update 3.1.56's release date