Re: WebAssembly Support (#18600)
Gunter Königsman
There is https://github.com/ahilss/wxWidgets-wasm which looks like building wxUniversal using emscripten already is a thing - but if I try to compile it I run into an error message:
checking host system type... Invalid configuration `emscripten': machine `emscripten-unknown' not recognized
configure: error: /bin/bash ../config.sub emscripten failed
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
Probably can be easily fixed by just updating the included config.{sub,guess} files to the latest upstream versions.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Gunter Königsman
Tried with the last git master of wxWidgets:
gunter@Marius:~/src/wxWidgets_WASM$ emconfigure ./configure --disable-shared --enable-universal
configure: ./configure --disable-shared --enable-universal
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for toolkit... gtk
checking for gcc... emcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/home/gunter/src/wxWidgets_WASM':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
emconfigure: error: './configure --disable-shared --enable-universal' failed (returned 1)
and:
gunter@Marius:~/src/wxWidgets_WASM$ emconfigure ./configure --disable-shared --enable-universal --host=emscripten
configure: ./configure --disable-shared --enable-universal --host=emscripten
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `emscripten': machine `emscripten-unknown' not recognized
configure: error: /bin/bash ./config.sub emscripten failed
emconfigure: error: './configure --disable-shared --enable-universal --host=emscripten' failed (returned 1)
What I want to port is a program that uses a quite big percentage of wxWidget's features (wxMaxima) => it is quite probable that I will get stuck in a place that wxUniversal is still not covering, anyway.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
A quick web search shows that the correct triplet for Emscripten for the GNU tools is asmjs-unknown-emscripten, i.e. you should use --host=asmjs-emscripten ("unknown" is inferred).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Gunter Königsman
Where did you find that? Now the only error message I get is:
configure: error: wxMicroSleep() can't be implemented
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Gunter Königsman
It naturally is possible that if that is fixed I'll get new ones.
Seems like not providing high-resolution timer is a measure against spectre and meltdown. For my purposes approximating wxMicroSleep(x) by wxMilliSleep(x/1000) plus maybe a warning whilst building wxWidgets would suffice. In the end most timers don't guarantee accuracy, anyway.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
Where did you find that?
The exact post was https://mail.gnu.org/archive/html/config-patches/2015-02/msg00019.html which was one of the first matches when searching for "config.sub emscripten".
Now the only error message I get is:
configure: error: wxMicroSleep() can't be implemented
You could replace this error with a warning and do the same for wxMicroSleep() implementation in src/unix/utilsunx.cpp.
But yes, I'd be surprised if this were the only problem. I don't know if ahilss/wxWidgets-wasm has already fixed more of them or not, but if you'd like to help with integrating Emscripten support (which would certainly be welcome!), please rebase the changes there on the latest master and create a PR to test them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
mps
I've gone the same path myself and successfully compiled an application after applying this patch. Also modified the build args a bit:
export CONFIGURE_ARGS=" --host=emscripten
--with-cxx=17
--enable-utf8
--enable-universal
--disable-shared
--disable-exceptions
--disable-richtext
--without-libtiff
--disable-xlocale
--disable-dependency-tracking
--enable-dynamicloader=no
--prefix=$(pwd)/install
--libdir=$(pwd)/install/lib64"
And finally for my application, increased the stack size and maximum heap, plus allow memory growth:
add_link_options("$<$CONFIG:DEBUG:-sASSERTIONS=1;-sDEMANGLE_SUPPORT=1;-sALLOW_MEMORY_GROWTH=1;-sMAXIMUM_MEMORY=4GB;-sSTACK_SIZE=5MB>")
The real issue I think is that the wasm implementation in that repo is lacking. If you compare src/gtk or src/qt with src/wasm in that repo, you'll see that 2/3 of the WxWidgets classes are missing an implementation.
Is WxWidgets looking to officially support wasm? Could be useful to tackle some of this stuff together if the commitment to maintain this longer term is there.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
I don't know what counts for "official" but it would certainly be good to have WASM support. It doesn't have to be complete to be useful but, of course, it would be even better if somebody would be interested in working on improving it further.
Personally I can't promise to do it, but I could still help someone who would.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
mps
I am looking to prepare a PR that merges @ahilss' changes into the head of this repository. However, I noticed that he removed the exception to the LGPLv2 license that wxWidgets grants, so I'm not sure merging the changes back into mainstream would technically be allowed. @ahilss are you still around?
I also do not understand their changes 100% since I am neither intimately familiar with wxWidgets nor wasm, so this will require a lot of feedback :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Stefan Csomor
As he restricts the license more than we do, we cannot merge such a PR IMHO, @vadz what do you think ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
In theory we could license wxWasm port under LGPL only, without the exception, but it would be very confusing and maybe misleading. There is a possibility that @ahilss removed it just because they believed it was inapplicable to wasm (because I'm not sure what does it mean to link statically in this context) but we can't assume this was the case without an explicit confirmation.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
