New package: emscripten

[truboxl]

No description provided.

[truboxl]

Please note that this is a build test. I haven't do proper running on device yet.
Just want to ask does GH Action also work on forked repo? So that I can test over my forked repo first...

[Grimler91]

Just want to ask does GH Action also work on forked repo? So that I can test over my forked repo first...

It does (except the upload job of course), you just need to enable github actions at the actions tab in your repo

[Grimler91]

@truboxl please consider setting yourself as TERMUX_PKG_MAINTAINER for emscripten, partly so that you get all the credit for the port, and partly since you would be the best person to solve possible future issues in the package

[finagolfin]

Still a draft?

[truboxl]

Sorry for the delay, testing a cross-compiled cross compiler is difficult and time wasting for me. I have been trying to compare the port with emsdk version which directly build emscripten on device from the tree. The summary:

1. Don't use -O2 and higher, binaryen wasm-opt will segfault, even on Hello world!. This also happens with emsdk version of binaryen. Not sure what is the problem. crash in wasm-opt at -O2 WebAssembly/binaryen#3697 seems to indicate that it has been fixed, and the code is present but still crashes

2. Some tests provided by emscripten itself: https://emscripten.org/docs/getting_started/test-suite.html, also fail. Can either be attributed to No.1, or third party tests that are not packaged, or x86 Linux only tests, or some other stuff. And the tests result may differ at each run. Also not sure what is the cause. https://gist.github.com/truboxl/4332a198fbc105e99fd7aeff954b83d2

   The constantly rolling emsdk version seems to fair better in tests than this port. https://gist.github.com/truboxl/53bf2d4aa44775be1d5e23d97f286d3c

   Maybe I will package the third party test as subpackage and wrestling portrm for that case in the next release...

3. emscripten-llvm has some bits from unreleased NDK that prevented it from using as native compiler. eg: missing libunwind support. [FR] switch all architectures to LLVM's libunwind android/ndk#1230 So just keep it for emscripten private use.

4. As long as you are not using some edge case options that are part of the failed test, the emscripten compiler just works. To be sure, I compiled https://github.com/OneLoneCoder/olcPixelGameEngine emscripten demo: https://www.youtube.com/watch?v=MrI5kkVY6zk It seems to work. Just don't use -O2.

I think @Grimler91 @buttaface and others can review now...

[truboxl]

For whatever reason, switching binaryen to debug build and wasm-opt segfaults go away, more core tests successfully pass...
I think I have to go back finding the root cause. Setting back to draft...

[truboxl]

Reported a new issue to binaryen upstream at WebAssembly/binaryen#3806
Looks like threading problem in Release build. Not sure how to fix that.

binaryen CMakeLists.txt forces -O2 or -O0. The -Oz is overridden anyway by one of those two. I think I will stick Debug -O0 which do not have threading problems. I don't think I want to patch CMakeLists.txt. What do you guys think?

[finagolfin]

I see no problem with patching the CMake config, do it all the time.

[truboxl]

Threading issue has been fixed in upstream so using that commit for binaryen, thus one less patch to maintain 🤣

https://gist.github.com/truboxl/91aac174873a05536244fb75ebb0d5de
The core tests passed with 96.8% ((712 - 9 - 12 - 54) / (712 - 54)) consistently so I am fairly confident with this port
The failures are down to not including 3rd party tests for space reasons and LLVM 13 not able to generate native code for now...

[truboxl]

Closes #5043

[ghost]

@truboxl Ready for merging?

[truboxl]

@xeffyr I believe I tested enough... 😂
For the really edge cases, its up to others to report their issues...

EDIT: Ready for merge if @termux approve

[ghost]

build.sh look fine. However there is a question about

TERMUX_PKG_RECOMMENDS="emscripten-llvm, emscripten-binaryen"

This will make packages emscripten-llvm and emscripten-binaryen installable among with emscripten by default (i.e. weak dependency). If this is not intended behavior, then TERMUX_PKG_SUGGESTS should be used instead.

[truboxl]

The emscripten package currently depends on a specific snapshot of LLVM and binaryen
so I split them up into smaller subpackages and use TERMUX_PKG_RECOMMENDS
Its pretty big if I combine all of them

I think I can use TERMUX_PKG_SUGGESTS once it no longer requires those specific versions of dependencies