Tests fail on Win 7 64-bit (Emscripten does not link against libcxx?)

[juj]

Preconditions:

• Have cloned emscripten and clang, and built clang using VS.
• Have installed python and node.
• Cygwin is installed.
• tools make, clang, llvm-ld, python, node are found in path.

Following the instructions of the tutorial on the web page:

Setting environment for using Microsoft Visual Studio 2010 x86 tools.

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>cd \Projects\emscripten

C:\Projects\emscripten>clang tests\hello_world.cpp

C:\Projects\emscripten>a.out
hello, world!

C:\Projects\emscripten>node tests\hello_world.js
hello, world!

C:\Projects\emscripten>python emcc
emcc: no input files

C:\Projects\emscripten>python emcc tests\hello_world.cpp
clang++: warning: argument unused during compilation: '-nostdinc++'

C:\Projects\emscripten>node a.out.js
hello, world!

C:\Projects\emscripten>python emcc tests\hello_world_sdl.cpp -o hello.html
clang++: warning: argument unused during compilation: '-nostdinc++'

(Tested loading hello.html in Firefox - works ok)

C:\Projects\emscripten>python emcc tests\hello_world_file.cpp -o hello.html --pr
eload-file tests\hello_world_file.txt
clang++: warning: argument unused during compilation: '-nostdinc++'

(Tested loading hello.html in Firefox - works ok)

C:\Projects\emscripten>python tests\runner.py test_hello_world
Running Emscripten tests...
(Emscripten: Running sanity checks)
test_hello_world (main.default) ... ok

---

Ran 1 test in 0.603s

OK

Up to this point, everything was ok. Then,

C:\Projects\emscripten>python emcc tests\hello_libcxx.cpp
clang++: warning: argument unused during compilation: '-nostdinc++'
Traceback (most recent call last):
File "emcc", line 789, in
extra_files_to_link.append(shared.Cache.get(name, create))
File "C:\Projects\emscripten\tools\shared.py", line 879, in get
shutil.copyfile(creator(), cachename)
File "C:\Python27\lib\shutil.py", line 81, in copyfile
with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: 'c:\users\clb\appdata\local\t
emp\emscripten_temp_bys7as\libcxx\libcxx.bc'

also, trying to run the tests with

C:\Projects\emscripten>python tests/runner.py

gives

http://pastebin.com/MFviweDX

and so on.. the test execution was aborted in between.

Also, compiling a custom application which uses the C++ std library and SDL gives

C:\Projects\Samples\vs_tool\Emcc Debug>node ClearScreen.js

node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
TypeError: undefined is not a function
at ___cxx_global_var_init5 (C:\Projects\Samples\vs_tool\Emcc Debug\ClearScre
en.js:939:3)
at __GLOBAL__I_a (C:\Projects\Samples\vs_tool\Emcc Debug\ClearScreen.js:1045
:3)
at callRuntimeCallbacks (C:\Projects\Samples\vs_tool\Emcc Debug\ClearScreen.
js:705:5)
at initRuntime (C:\Projects\Samples\vs_tool\Emcc Debug\ClearScreen.js:714:3)

at Object.<anonymous> (C:\Projects\Samples\vs_tool\Emcc Debug\ClearScreen.js

:2032:1)
at Module._compile (module.js:441:26)
at Object..js (module.js:459:10)
at Module.load (module.js:348:31)
at Function._load (module.js:308:12)
at Array.0 (module.js:479:10)

which is apparently result of not linking against libcxx?

[juj]

I find that I do not have libcxx.bc anywhere on my system. There is a directory emscripten\system\lib\libcxx, which has a Makefile that has been set up to build libcxx.bc.

Is building libcxx.bc a manual task that needs to be done before building with emscripten? or should it occur automatically as part of the build process when something requiring libcxx is compiled with emscripten?

[kripken]

It should occur automatically. We build libraries once and store them in ~/.emscripten_cache. You should have dlmalloc and libcxx there if you built programs that use them. What are the contents of that directory for you?

[matt456]

Just to chime in here, I have exactly the same set-up win7 and 64bit. I used msys rather than cygwin however. I get the same issue and in me ~/.emscripten_cache folder all I have is dlmalloc.bc.

I'll be trying to compile libcxx manually to see how that fairs. thanks.

[juj]

I managed to manually build libcxx and libcxxabi in emscripten by adjusting the makefiles a bit. I pushed my toyings into the branch juj@304ff3d .

After that change the emscripten_cache folder contains dlmalloc.bc, libcxx.bc, libcxxabi.bc (before that there's only libcxxabi.bc)

A sidenote: the file 'readme.txt' shouldn't probably occur here? juj@304ff3d#L1L15

[matt456]

Thanks, I found that part of the path to clang was being duplicated when trying to build libcxx and libcxxabi e.g.

C:/SDKs/MingW/msys/1.0/SDKs/MingW/msys/1.0/local/bin/clang++
where it should have been
C:/SDKs/MingW/msys/1.0/local/bin/clang++

I simply modified my emscripten config file to use a different path to clang (it was /SDKs/MingW/msys/1.0/local/bin/) to another folder in my case ~/build/Debug/bin where I had compiled clang previously.

That worked, I think the cause of the bug is the path mangling, by using a ~/.... path I skipped the full path usage I had previously had that was causing a problem. This stems from needing to define a path inside the mingw32 shell that python can find also.

[kripken]

@juj yeah, readme should not be there ;) thanks, I'll fix that.

@juj Which of the changes in your branch are needed to fix this? Some like -DEMSCRIPTEN should not be necessary I don't think. Unless clang is being invoked there and not emcc?

@matt456 I didn't quite follow that. Is there something we can do in emscripten to prevent the problem you worked around?

[kripken]

@daoshengmu : That looks like a separate issue if you can't get hello world to run. Please file a separate issue so we can keep the discussions separate and clear.

[daoshengmu]

I have modified Makefiles and emcc as @juj, it still can't generate libcxx and libcxxabi.bc. My OS is Windows XP, I use "visual studio 2008 command prompt" to execute commands, and I just build clang.exe, clang++.exe, clang-tblgen.exe, llvm-dis.exe, llvm-nm.exe, llvm-tblgen.exe, and opt.exe from LLVM.sln.

I don't know whether I should build other execution files from LLVM?

[juj]

kripken: I believe that I did invoke clang directly (set env. var CXX=clang because it was not manually detected for some reason, and set CXXLINK=llvm-ld), therefore I had to manually hack in the same compilation parameters that emcc did.

Setting CXX=emcc just didn't occur to me at that point, that'd be a better solution. Although I have not tried it to confirm that it will work.

The changes to file tests/msvc10/hello_libcxx.vcxproj are completely unrelated to this tracker item.

I think there's three relevant modifications that might be needed:

• manually set CXX=emcc. Without this I had make defaulting to MinGW gcc on my system, even tough I had removed MinGW from path while trying to build
• removed that readme.txt, which caused build to fail (perhaps it wouldn't have if I had used CXX=emcc)
• manually invoke the build with 'make' in the directories libcxx and libcxxabi. It seems like these were never invoked automatically, or if they did, I never saw any diagnostics/error messages about them.

Now that I built libcxx and libcxxabi manually, I managed to build and run the hello_libcxx test from the command line, although I'm still having problems setting up MSVC to do the build. I switched to MSVC invoking emcc instead of clang as well, so will try out how that goes.

DaoshengMu: I recommend just building all the tools there are in LLVM.sln, and also make sure that you have the latest tagged release (3.0) and not the current trunk, since the trunk version has deleted the llvm-ld tool in favor of always using llvm-link tool.

[kripken]

@juj: The makefile uses $(CXX), and we run it through emmake which defines that env var. Does that definition not work on windows for some reason, and that is the problem?

[juj]

Meh, I had run 'make' and not 'emmake'. That accounts for a lot of my issues. I'll try out cleaning the build and redoing with emmake.

On a clean git clone, am I expected to run emmake on libcxx and libcxxabi folders manually before building e.g. hello_libcxx, or is that something that should occur automatically while emcc is used to build a project that uses C++ stl?

[daoshengmu]

@juj , I replace llvm&clang from trunk version with 3.0, and update the latest version of Emscripten. I have already generated libcxx and libcxxabi.bc. Thanks for your help.

[kripken]

@juj: it should be 100% automatic. the problem might be that it does not happen correctly on windows for some reason. Basically, what happens is this:

1. If ~/.emscripten_cache does not contain libcxx.bc, then
2. create_libcxx is called in emcc which calls tools/shared.py's build_library.
3. That builds libcxx in a temp dir, with an environment that sets CXX to emcc and calls Building.make (which is exactly what emmake does).

If this does not work on windows, perhaps setting the environment needs to be done differently there?

[kripken]

Perhaps the windows environment works differently in cygwin than otherwise, or something like that?

[juj]

Trying to run emmake gives

C:\Projects\emscripten\system\lib>cd libcxx

C:\Projects\emscripten\system\lib\libcxx>python c:\projects\emscripten\emmake
Traceback (most recent call last):
File "c:\projects\emscripten\emmake", line 24, in
shared.Building.make(sys.argv[1:])
File "c:\projects\emscripten\tools\shared.py", line 471, in make
Popen(args, stdout=stdout, stderr=stderr, env=env).communicate()
File "C:\Python27\lib\subprocess.py", line 679, in init
errread, errwrite)
File "C:\Python27\lib\subprocess.py", line 893, in _execute_child
startupinfo)
WindowsError: [Error 87] The parameter is incorrect

C:\Projects\emscripten\system\lib\libcxx>cd ..

C:\Projects\emscripten\system\lib>cd libcxxapi
The system cannot find the path specified.

C:\Projects\emscripten\system\lib>python c:\projects\emscripten\emmake
Traceback (most recent call last):
File "c:\projects\emscripten\emmake", line 24, in
shared.Building.make(sys.argv[1:])
File "c:\projects\emscripten\tools\shared.py", line 471, in make
Popen(args, stdout=stdout, stderr=stderr, env=env).communicate()
File "C:\Python27\lib\subprocess.py", line 679, in init
errread, errwrite)
File "C:\Python27\lib\subprocess.py", line 893, in _execute_child
startupinfo)
WindowsError: [Error 87] The parameter is incorrect

C:\Projects\emscripten\system\lib>

[juj]

in above, in shared.py, line 471, adding 'print args' gives an empty string: 'args: []'

[juj]

Actually reading the documentation, I'm supposed to pass 'make' as the first command line parameter. Rerunning:

C:\Projects\emscripten\system\lib\libcxx>python c:\projects\emscripten\emmake ma
ke
python 'c:\projects\emscripten\em++' algorithm.bc condition_variable.bc futur
e.bc iostream.bc memory.bc random.bc stdexcept.bc system_error.bc utility.bc bin
d.bc debug.bc hash.bc mutex.bc string.bc thread.bc valarray.bc chrono.bc excepti
on.bc ios.bc locale.bc regex.bc strstream.bc typeinfo.bc -o libcxx.bc
(Emscripten: Config file changed, clearing cache)
(Emscripten: Running sanity checks)
FATAL: Cannot find C:\Cygwin\home\clb/Dev/llvm-3.0/cbuild/bin\clang++, check the
paths in ~/.emscripten

My .emscripten looks like this: http://pastebin.com/hTjs5kn0

[juj]

Ah, now I see what is happening, although I don't know why.

I added a trace print line to line 40 in shared.py:
print 'Loading emcc configuration from:', CONFIG_FILE
exec(open(CONFIG_FILE, 'r').read() if CONFIG_FILE else EM_CONFIG)

After that, running emmake reveals:

C:\Projects\emscripten\system\lib\libcxx>python c:\projects\emscripten\emmake ma
ke
Loading emcc configuration from: C:\Users\clb/.emscripten
python 'c:\projects\emscripten\em++' algorithm.bc condition_variable.bc futur
e.bc iostream.bc memory.bc random.bc stdexcept.bc system_error.bc utility.bc bin
d.bc debug.bc hash.bc mutex.bc string.bc thread.bc valarray.bc chrono.bc excepti
on.bc ios.bc locale.bc regex.bc strstream.bc typeinfo.bc -o libcxx.bc
Loading emcc configuration from: C:\Cygwin\home\clb/.emscripten
Loading emcc configuration from: C:\Cygwin\home\clb/.emscripten

For some reason, emcc goes to look for Cygwin paths for my home directory on the second pass. I looked and noticed that C:\Cygwin\home\clb.emscripten contains the default unmodified settings.py with wrong paths. As a workaround, I duplicated my own C:\Users\clb/.emscripten to C:\Cygwin\home\clb/.emscripten as well, and now the build succeeds fine.

Somewhere in between the invokation of emmake and em++, emscripten mixes cygwin and windows environments and goes to look at cygwin folders. This occurs in 'os.path.expanduser(EM_CONFIG)', which returns C:\Users\clb/.emscripten on the first go, but C:\Cygwin\home\clb/.emscripten on the subsequent times.

[kripken]

This is all very confusing to me, mostly because I know little about windows and less about cygwin... But can't we find out where the environments get mixed up? Maybe we need to copy the environment somewhere where cygwin doesn't do it for us?

[juj]

I'm quite much a beginner with cygwin as well. I think what's happening is that somewhere along the execution something is overwriting windows env. variables HOMEDRIVE/HOMEPATH or USERPROFILE to point to Cygwin's version of the user home directory. I don't think that should be happening at all.

Emscripten shouldn't have anything to do with Cygwin, and only python, llvm and clang are required, right? So if I uninstalled cygwin emcc should still work(?). I'll try that once I get a chance and see if there's a way to have existing Cygwin not mess things up and investigate what messes up the paths.

[kripken]

Any updates here?

[juj]

The last I touched this was about three weeks ago, when I got a new laptop. The situation still was then, that I must have cygwin and I must copy my .emscripten to the cygwin user home directory as well, from my C:\Users\clb/.emscripten, or otherwise the libcxx.bc and will fail to automatically build.

[kripken]

Ok, then sounds like things are ok, we just need cygwin (and .emscripten in cygwin's home dir)? I'll add that to the tutorial page.

[juj]

Well yes, that could be made a manual documented work step. Note that the same .emscripten file needs to be present in both directories C:\Users\clb/.emscripten and C:\Cygwin\home\clb/.emscripten, since emcc tries to look for both files during its run, so just the cygwin location is not enough.

[kripken]

Is there some way to set up Cygwin to map one to the other? Or should we copy it to the Cygwin dir ourselves? (I don't know how windows apps normally work..)

[Dazdfa]

I had a similar problem, but I believe I've found why the environments get confused. Basically, build_library() in shared.py tries to call the "make" command, but on juj's system, the first one in his path is the GNU make in his Cygwin installation. That version of make is set up to expect things strictly where Cygwin puts them.

The solution is to ensure a non-Cygwin make is found first in the path.

[kripken]

Hmm, is there some way we can at least warn about this, when it happens?

[Dazdfa]

You could check if the make command in build_library() has failed, and if so, try running "make --v" to get the version and see if the resulting output contains the string "cygwin". (On my Cygwin make, the second line of the version output is "Built for i686-pc-cygwin".)

If so, the code could display a warning that the user should ensure a non-Cygwin version of make is installed and can be found earlier in the path than the Cygwin one.

[kripken]

Thanks, makes sense.

I decided in the end to rewrite the libcxx and libcxxabi building code to not use makefiles at all. Hopefully this will fix a whole set of issues we have had on windows with the least risk of odd problems, make is no longer needed for libcxx and libcxxabi.

If anyone can test latest incoming branch on windows to see if it helps that would be great. (I can see the change did not break stuff on linux.)

[juj]

While some tests and benchmarks on windows require cygwin, using emscripten itself does not need it anymore. One can use mingw32-make to act as a native make tool with emscripten for build systems.

The issue that was originally raised here has long been fixed. All tests, except those that have been explicitly skipped due to known issues tracked in other items, pass on latest incoming on Windows, and libcxx builds fine after the recent Std pull request merge, so closing this issue as resolved.