Errors compiling with emscripten

[progfrosty]

It looks like the emscripten build might have some issues on Macos X 10.15.2. I'm using the latest emsdk and running the 'make-emscripten' build. Mostly seems to work except I get errors about:

....../microwindows/src/nanox/srvnonet.c:11:10: fatal error: 'emscripten.h' file not found

and also missing ft2build.h

It does build to completion, but the resultant 'binary' doesnt run.

I did notice that I had to use

emsdk install latest-fastcomp & emsdk activate latest-fastcomp

as well.

[ghaerr]

IIRC the couple errors displayed are strange, but normal, and the compilation continues.

Did you ever have this compiling/working on a previous macOS system? I seem to remember that you also have to pull down the SDL 2 library (and possibly others) to get it to run. The emsdk environment does late binding and dies when it can't find a linkage, I think.

I'm running 10.14.6 on a laptop, I can try building from scratch to try to duplicate this if you need more help.

[progfrosty]

Managed to get it to compile OK without errors. The demos now run, but on Chrome they lock up after the first screen is displayed and dont respond to the mouse. Might be something minor? mwdemo.html does work OK on firefox though.

[progfrosty]

Yes - most of the demos have the same issue. They run, but then hang, the browser then gives the 'page is unresponsive' message. This is with the latest 1.39 version of emscripten.

Note they have moved to WASM output now by default, so you have to activate legacy fastcomp code. I wonder if it should be moved to the regular latest code. I did try this but ran into linker issues and dont know enough about microwindows yet to debug.

[progfrosty]

Should also run a bit quicker with the wasm variant of emscripten

[ghaerr]

Note they have moved to WASM output now by default, so you have to activate legacy fastcomp code.

Ah - that's the problem. I tried getting Microwindows running with WASM in the past, but long story short, we require the emscripten_sleep function due to our architecture. Its a bit complicated to explain, see src/demos/Makefile-emscripten*.

Can you disable the wasm output and instead produce the other alternative? I think that will at least temporarily solve this problem.

[progfrosty]

Understand re the emscripten_sleep, note this is a syncronous sleep though, so not sure if that's what you need ? I think you might need ASYNC=1 and then emscripten_sleep_with_yield ?

[progfrosty]

I'm building a stack for wxWidgets -> microwindows -> emscripten by the way, hence the interest. I have a working wxWidgets custom build that uses self drawn widgets runninng on raw X11 (no other libs), so there is potentially a route here.

[ghaerr]

Understand re the emscripten_sleep, note this is a syncronous sleep though, so not sure if that's what you need?

No, we need a synchronous sleep since the Microwindows main loop requires that the stack frame that it sets up remain intact while emscripten runs. That is because of the location where we end up having to call emscripten_sleep, which is in the near the otherwise 'select' call. All the routines that are in that stack have been special cased, which is the reason they are whitelisted in the EMTERPRETIFY section of the demos/Makefile-emscripten. That is for the nano-X programs.

For the win32 programs (mwdemo.html), things operate a bit differently, since the sleep can occur in the essentially callback-driven "Windows" main loop. That's why you're seeing different results based on the API used to construct the demos.

[progfrosty]

Hi - unfortunately all demos (nx/x/mwin/etc) get stuck. They all do the inital draw and then hang, so its definitely something to do with the loop. I'll play around and see if I can figure it out :)

[progfrosty]

So interesting, I went back to Jan 25th in the repo history, compiled again and everything works fine. I guess something changed somewhere to break things.

[ghaerr]

I went back to Jan 25th in the repo history, compiled again and everything works fine.

Geez. It looks like there was a big change to src/demos/Makefile-emscripten the next day, that could have done it. I think I still have the older emscripten on my system, I'll try compiling it up and see what happens.

Did you see the documentation in src/docs/EMSCRIPTEN.rules? This attempts some documentation on the interface between Microwindows and emscripten.

[progfrosty]

Brill thanks. I did see the EMPSCRIPTEN.rules file thanks.

[progfrosty]

Note I've generally found the .wasm files are a lot faster, but appreciate that it may not be possible to get that working.

[ghaerr]

Yes, I gave it a good try, but they don't support WASM with the stack-based sleep. Ugh.

[ghaerr]

Actually the real problem is that I have to have "interpreted" code so that the stack can be saved. WASM and the web browser are all built around async callbacks. This could possibly be gotten around in Mwin, but it would take some serious (re)thinking.

[progfrosty]

Yes, it looks like the changes after Jan 25 messed up the emscripten build - I wondered if it was connected with the function list ? Perhaps something missing or in the wrong list?

[ghaerr]

Yes, it looks like the changes after Jan 25 messed up the emscripten build

I'm trying to get the emscripten build working with my old version of emscripten to check what caused this... but somehow my python version changed to v2.7.15, and now emscripten won't compile anything. Grrr...

[progfrosty]

I managed to compile the Jan 25 version with the latest emscripten (latest-fastcomp) if that helps?

[ghaerr]

I managed to compile the Jan 25 version with the latest emscripten (latest-fastcomp) if that helps?

That's good to know. So you've compiled the Jan 25 version unmodified with the latest emscripten and it works? That means the problem is definitely in the subsequent commits. I'll take another pass at trying to get python updated before upgrading emscripten.

Did you try the Jan 26 version, does that fail, or is it in a commit after that? Unfortunately, it looks like the Jan 26 version is a large commit.

[progfrosty]

Yes - seemed to compile fine on 25 Jan. I went forward to mid/late Feb, and it failed, but didnt check each commit. I'm guessing you are right though.

[ghaerr]

Quick question: weren't you saying that one has to add a something to the compile/make (even for the Jan 25 version) when using the latest emscripten, because the default output is now WASM?

There are so many variables here, that's why I'm hesitating upgrading emscripten as it could start a deep rabbit hole.

[progfrosty]

I actually just compiled 'as is' with no changes to your configs, as I wanted to get back to a point where it was working OK. I did have a try at compiling for WASM but the compiled code wouldnt run, I realise now its because of the loop.

[progfrosty]

One thing you do have to do though, is run the latest-fastcomp variant of emscripten, which is the legacy version. Once you've installed emsdk, use emsdk install latest-fastcomp, then emsdk activate latest-fastcomp, you then proceed as normal.

[progfrosty]

The latest empscripten doesnt support the ASYNC methods in the same way as before. The fastcomp version supports all the options in your config script :)

[ghaerr]

Ok, found out I had a working older emscripten on my laptop. I compiled the latest version of Microwindows with it and everything works. emcc --version reports emcc (Emscripten gcc/clang-like replacement) 1.38.24 (commit ea5d631a5446632e195765d89a53ead71cd6de45)

Any chance you can get that version?

Specifically:

cp Configs/config.emscripten config
make clean
make
./make-emscripten
./emrun mwdemo
./emrun demo-composite

[georgp24]

I'm building a stack for wxWidgets -> microwindows -> emscripten by the way, hence the interest. I have a working wxWidgets custom build that uses self drawn widgets runninng on raw X11 (no other libs), so there is potentially a route here.

Do you have this stack working with wxWidgets -> microwindows ->Linux already ? Do you have this code on GitHub?

[progfrosty]

@georgp24 not yet - I have wxWidgets -> X11, working on getting NanoX working.

[georgp24]

I committed my application note how to get wxWidgets version 2.4.2 running with Nano-X. https://github.com/ghaerr/microwindows/blob/master/doc/pdf/wxWidgets%20App%20Note-2.4.2.pdf I did not get any later version of wxWidgets to work with Nano-X but maybe this document helps you to get your wxWidgets custom build to run with Nano-X.

[pmp-p]

your work is impressive !

at first try mwdemo runs fine on webassembly for me (clang11), just removing EMTERPRETER* stuff and adding -s ASYNCIFY=1

are there any potentially blocking functions in the X-server, or that's just client busywait ?

also i wonder if it's possible to have a wasm tcl/tk on top of it ? ( CPython is often shipped with tkinter )

[ghaerr]

your work is impressive !

Thanks. This emscripten stuff is a bit complicated and works with older emscripten, there are still possible issues with the latest version(s).

at first try mwdemo runs fine on webassembly for me (clang11), just removing EMTERPRETER* stuff and adding -s ASYNCIFY=1

The mwdemo applications are built using the WIN32 API, whose application main loop and callback structure are such that operation within the emscripten non-emterpreter environment are significantly easier. The Nano-X applications have main loops outside of the "system" (in the application instead) and can arbitrary call graphical functions, instead of using WIN32 style window callback functions. This means that there is a stack frame that must be protected when blocking.

are there any potentially blocking functions in the X-server, or that's just client busywait ?

Yes. It's a bit complicated, but the protected functions are whitelisted in demos/Makefile-emscripten. I haven't been able to find a way run nano-X (X11) applications differently, unless the main loop were taken out of the application. This is the reason why web assembly isn't working for nano-X API applications. With an appropriate "application framework" that restricted the main loop and callout functions, this could possibly be achieved.

also i wonder if it's possible to have a wasm tcl/tk on top of it ? ( CPython is often shipped with tkinter )

Please explain more what you are trying to do?

[pmp-p]

Please explain more what you are trying to do?

i try to maintain 2 Python Virtual Machines on android and webassembly ( cpython / micropython-pycopy ) and one specific to bare wasm ( it can be preempted and python vm loop can return to javascript allowing a lot of blocking I/O operations on time or socket/files ).

cpython: http://pmp-p.github.io/panda3d-next/py3/ micropython: https://pmp-p.github.io/micropython-next/dom-rw.html

CPython beginners with GUI often start with tkinter because it's documented https://docs.python.org/3/library/tkinter.html and often available for free on desktop OS.

but actually python-tkinter is not available for free on android or (not at all) on wasm, i've found recently https://www.androwish.org/home/home and it lead me via the AGG link just ... here with some hope to maybe build some basic tkinter support on wasm :)

With an appropriate "application framework" that restricted the main loop and callout functions, this could possibly be achieved.

yes it's possible to remove emscripten_sleep and ASYNCIFY/EMTERPRETER ( their speed cost is high ) https://pmp-p.github.io/mwin_sync/ with eg an arduino style setup/loop https://pmp-p.github.io/mwin_sync/xhello.c

( note that previouly i did not use older emscripten , but a future version of it named "tot" (tip of tree) under continuous integration so my advice about ASYNCIFY may work or not on regular emscripten and code that need emscripten_sleep )