Robust emsdk builds

@juj

We need to figure out a robust solution to emsdk build generation. Over the last months we had a few weeks where this was broken, and users could only get incoming and build it manually.

The main thing we need to ensure is that more than one person can do this, unlike now where only @juj can.

Some thoughts:

Aside from our own emsdk efforts, others exist like OS X homebrew and a linux docker image. I also constantly have a local linux build myself. Maybe we can collaborate there, make it easy to upload builds the emsdk can use?
Another option discussed has been to use a port of llvm+clang to asm.js or wasm, which would be a portable build usable anywhere. However, it would be slower.

wasm build will always be valuable as it will be able to run on arbitrary OS, including ones currently unsupported (ChromeOS? and older/newer versions of Ubuntu). And it will better match npm (#5774). (npm install llvm!)

Emsdk build generation is being migrated to Amazon EC instances, so one solution might be to hand off credentials to those to more people. Would that be enough of a solution?

@saschanaz

@saschanaz : yeah, I think the wasm build could be useful for a bunch of things. What worries me there is (1) it'll be slower, but more convenient, so people might end up using it a lot, and (2) it's another build to maintain and test (easier than each of the existing native builds, but still, another build target).

@juj : I think that would be enough, unless it requires a windows machine to do something for the windows build - like debug it when building fails (I don't have one of those currently, for example). What would those people be able to do, and what would the interface for them be?

it'll be slower, but more convenient, so people might end up using it a lot

npm supports a post-installation hook where we can warn that this wasm-based package can be slower.

Another important thing for robustness is to monitor that our emsdk builds are being generated (there are reports right now of new breakage in #5713). A dashboard perhaps? Anyhow, this is lower priority than the other stuff here, probably.

CircleCI has Git Tag Job Execution where we can automatically trigger build jobs, exactly what the current bots do. My expectation is that the CI can build each tools within its 50 min limit but currently I don't have enough knowledge about cmake to actually try it...

(Edit: talking about wasm build)

@saschanaz

@saschanaz Oh, nice! Yeah, that's worth trying.

Can I help with this? I'm interested specifically in helping with a WASM build of Emscripten. I know very little of the internals of Emscripten, but I've been messing around with Emscripten's WASM compilation as a user. I could really use a WASM build for a Node.js based project where I need dynamic compilation of C/C++ and other files, unfortunately it takes forever to install the Emscripten WASM toolchain, and I can't control the machines of my users. Having a WASM build should fix all of that I'm hoping. If anyone could point me in the right direction and explain the complexity of this, I'll see if I have the time.

@lastmjs

@lastmjs glad to hear you're interested to help :)

Overall, to get a wasm/js build of emscripten so that we can run it through node would need a few things:

Emscripten ports of the LLVM tools: llc, clang, llvm-link, opt. That means getting them to build using emscripten. The LLVM build system is a little tricky since it builds stuff it runs in the build process (tablegen), but this has been done (recently, clang-in-browser).
A solution for the python stuff. One option is to just run the python interpreter in wasm. We may need to add some new code for that as it likely uses system APIs we don't support yet, and may need the emterpreter for synchronous code, but it should be doable. Another option is to just assume python is present, which is usually easy to install if it isn't.

Btw, are you building emscripten from source? It shouldn't take a long time to install (which you mentioned) if there is a binary build and it's just downloaded. If that's not working properly for you then could be a bug there, but it should be working on all major platforms.

I meant building from source, not installing :) Okay, so Emscripten ports of the LLVM tools:

llc
clang
llvm-link
opt

Are there any other examples of this besides https://tbfleming.github.io/cib/ ? Also, is that an exhaustive list of the LLVM tools that would need to be ported to Emscripten? Would I be compiling them to WASM or just JavaScript? Where should I be hosting these changes (repo)? Is there a better place for me to ask questions, I imagine I'll have quite a few more

My plan right now is to play around with https://github.com/kripken/emscripten-fastcomp and try to build https://github.com/kripken/emscripten-fastcomp-clang with Emscripten. I can fork those repositories and make any changes necessary to them and pull request back. Is this a good direction?

I'm here in building clang with Emscripten:

emcmake cmake .. -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD="X86;JSBackend" -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF -DCLANG_INCLUDE_TESTS=OFF

What should I have for the option DLLVM_TARGETS_TO_BUILD?

The command above failed on the first try, but succeeded on subsequent tries. Now I've run into this issue:

[lastmjs@lastmjs build]$ emmake make
[  1%] Built target LLVMDemangle
[  1%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Path.cpp.o
In file included from /home/lastmjs/development/fastcomp-emscripten-build/emscripten-fastcomp/lib/Support/Path.cpp:1048:
/home/lastmjs/development/fastcomp-emscripten-build/emscripten-fastcomp/lib/Support/Unix/Path.inc:390:13: error: no member named 'f_flags' in 'statvfs'
  return !!(STATVFS_F_FLAG(Vfs) & MNT_LOCAL);
            ^~~~~~~~~~~~~~~~~~~
/home/lastmjs/development/fastcomp-emscripten-build/emscripten-fastcomp/lib/Support/Unix/Path.inc:103:35: note: expanded from macro 'STATVFS_F_FLAG'
#define STATVFS_F_FLAG(vfs) (vfs).f_flags
                            ~~~~~ ^
/home/lastmjs/development/fastcomp-emscripten-build/emscripten-fastcomp/lib/Support/Unix/Path.inc:390:35: error: use of undeclared identifier 'MNT_LOCAL'
  return !!(STATVFS_F_FLAG(Vfs) & MNT_LOCAL);
                                  ^
2 errors generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/build.make:2464: lib/Support/CMakeFiles/LLVMSupport.dir/Path.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:431: lib/Support/CMakeFiles/LLVMSupport.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

I assume there is an issue with including statvfs, any pointers here?

Unless fixing that limitation in the JSBackend isn't too difficult. What's the process there?

Can I help with this? I'm interested specifically in helping with a WASM build of Emscripten. I know very little of the internals of Emscripten, but I've been messing around with Emscripten's WASM compilation as a user.

Nice to see you working on this front, more developers working on in-browser compilation of C++ to Wasm is good. This bug entry discusses the maintenance of the native Emscripten SDK and not running Emsdk inside a browser, so let's keep this one clear for that, and collaborate on Emscripten build of Emscripten in a separate tracked entry. I think there was one already either in GitHub or emscripten-discuss mailing list.

@lastmjs

@lastmjs

To find which function it's in, you can run with EMCC_DEBUG=1, then the bitcode file is saved in the temp dir. Then do llvm-dis on it, and you can search for that line, then see the function (search backwards for define ).

Fixing the JSBackend would involve finding where that error is emitted (one of the passes under lib/Target/JSBackend/NaCl/, can search for the error text), and then implementing the missing thing there. In this case, it's probably going to be implementing lowering of signed comparisons of things like 150 bit integers into 32-bit ones. Not super-hard, but needs to be done carefully with all the corner cases.

@juj

@juj I can't seem to find the GitHub issue, do you know where it is, or perhaps I should open a new issue?

@lastmjs

@lastmjs I can't seem to find a specific issue for that either - might as well open a new one I think.

I'm trying to get Zig built with emscripten, and to do that the first step is the LLVM dependency. I get stuck at the error noted in #6015 (comment). My cmake line is:

emconfigure cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/local/llvm8-wasm -DCMAKE_PREFIX_PATH=$HOME/local/llvm8-wasm -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD="WebAssembly" -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF

In file included from /home/andy/downloads/llvm-project/llvm/lib/Support/Path.cpp:1110:
/home/andy/downloads/llvm-project/llvm/lib/Support/Unix/Path.inc:410:13: error: no member named
      'f_flags' in 'statvfs'
  return !!(STATVFS_F_FLAG(Vfs) & MNT_LOCAL);
            ^~~~~~~~~~~~~~~~~~~
/home/andy/downloads/llvm-project/llvm/lib/Support/Unix/Path.inc:91:35: note: expanded from macro
      'STATVFS_F_FLAG'
#define STATVFS_F_FLAG(vfs) (vfs).f_flags
                            ~~~~~ ^
/home/andy/downloads/llvm-project/llvm/lib/Support/Unix/Path.inc:410:35: error: use of undeclared
      identifier 'MNT_LOCAL'
  return !!(STATVFS_F_FLAG(Vfs) & MNT_LOCAL);
                                  ^
2 errors generated.
shared:ERROR: compiler frontend failed to generate LLVM bitcode, halting

This is on NixOS with llvm 8.0.1, emcc 1.38.28.

@andrewrk

@andrewrk cool, always interesting to hear about a new language here!

I'd actually suggest not building fastcomp - it's only guaranteed to work on clang, and not other LLVM-using compilers. Also, a more recent upstream LLVM is more likely to build out of the box on recent compilers, so it might not hit the errors you are seeing. We intend to switch to upstream LLVM pretty soon, we'll probably have a blogpost about that next week. Meanwhile, you can just get normal upstream LLVM and build it according to their instructions (making sure to build clang and lld, using something like -DLLVM_ENABLE_PROJECTS=lld;clang'). Then just point emscripten to that.

@kripken

Thanks for the tips @kripken! Just to be clear I wasn't using fastcomp - I don't even know what that is. I see now that it's mentioned above in this issue. I'll try with llvm trunk.

@kripken

@kripken I tried with LLVM trunk (git mono repo sha 046d49a8dcbbb99596ace2592aa0386ddf2f6bce) and got the same compile error. Is #6432 a better place to discuss this?

@andrewrk

@andrewrk that sounds like a bug in upstream llvm then, or it's not compatible with your compiler - which version is it? (recent clang should work, as should recent gcc, but old ones, or bleeding-edge versions of gcc, may be risky in my experience)

See #6432 (comment)

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

The original issue here has been fixed by the now over 1 year old chromium build infrastructure that powers the emsdk.

There are some other issues discussed in the comments, though - please open new issues for those if still relevant.

Navigation Menu

Repository navigation

Robust emsdk builds #6015

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Robust emsdk builds #6015

Description

Activity

saschanaz commented on Jan 3, 2018

juj commented on Jan 3, 2018

kripken commented on Jan 3, 2018

saschanaz commented on Jan 4, 2018

kripken commented on Jan 10, 2018

saschanaz commented on Jan 11, 2018

kripken commented on Jan 11, 2018

lastmjs commented on Apr 2, 2018

kripken commented on Apr 2, 2018

lastmjs commented on Apr 3, 2018

lastmjs commented on Apr 3, 2018

lastmjs commented on Apr 3, 2018

lastmjs commented on Apr 3, 2018

9 remaining items

lastmjs commented on Apr 4, 2018

juj commented on Apr 4, 2018

kripken commented on Apr 4, 2018

lastmjs commented on Apr 5, 2018

kripken commented on Apr 5, 2018

andrewrk commented on Jun 19, 2019

kripken commented on Jun 19, 2019

andrewrk commented on Jun 19, 2019

andrewrk commented on Jun 19, 2019

kripken commented on Jun 19, 2019

andrewrk commented on Jun 19, 2019

stale commented on Jun 18, 2020

kripken commented on Jun 18, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions