Build fail on debian(jessie)

[coddoge]

Seem the build instructions's params is specificed for OSX.
I have not mac, but i still try following instructions to build on debian(jessie) and fail.
Maybe some params differ between OSX and debian.
Please give some help! Thanks!

I am a dotnet developper, Very enjoying to using CSharp to develope software.
Now tasteing CSharp to wasm.

Thanks again!

[kekekeks]

Mkay, I've managed to build it on Linux using 32-bit chroot and to actually produce a wasm file, but I'm getting _extenddftf2 not implemented error from index.js.

It seems to be something wrong with my libc or LLVM build.

Main issues I've encountered during the build:

1. README lacks information about dependency versions. I had to guess and try to find ones that don't fail the build. That's the most major problem, since I have no idea if issues are simply caused by wrong dependency version.

2. There is no information about generating ./arch/wasm32/bits/alltypes.h. I had to patch configure script manually, but that doesn't seem to be the intended way of doing this.

3. It seems that wasm profile now has it's own mscorlib with separate sources list, but there is no information how to build it. It's not clear that it has to be built outside of the main build process.
   I had to change /mcs/class/corlib/corlib.dll.sources to include new sources

Linux-specific issues:

4. Makefile script for mono-wasm is not compatible with Linux, it tries to get libc sources in incompatible way, so ls fails. I also had to add -Wl,--whole-archive before binaryen libs to avoid unresolved symbol errors.

5. mono-wasm.cpp uses platform-dependent mach/mach_time.h, makes assumptions about how realpath works (it can't be used with relative paths that end with a file name), uses strlcat and >& in system command line. I'll make a PR with platform portability changes later.

@lrz any idea what might be causing _extenddftf2 error?

Also, please, use submodules to reference external dependencies. It would be nightmarish to track them otherwise.

I'm currently using r305964 for llvm, r306065 for clang and bc46556496b8086941076ff61bfa481344c1f0d1 for binaryen. My build environment almost certainly doesn't match yours.

[kekekeks]

Mono also seems to be failing to emit several methods due to this: https://github.com/mono/mono/blob/master/mono/mini/mini-x86.c#L1260

That's probably a known issue.