[Qt-creator] WebAssembly rough edges

Alessandro Portale alessandro.portale at qt.io
Thu Dec 17 06:50:52 CET 2020

Hello Alejandro,

I apologize for the late answer. In a nutshell: the current Qt for WebAssembly plugin in Qt Creator (unfortunately also in the upcoming 4.14) is de facto unusable with the current emsdk. Qt Creator 4.15 will fix these issues.

Friday, November 27, 2020, 7:12:44 AM, you wrote:

> I can get WebAssembly working for my project on Linux, but I feel I'm
> missing something, or there seem to be a few important gaps in Qt
> Creator.

> 1. The latest Qt Creator manual refers to the WASM plugin as
> "experimental", but the plugin itself is not marked like this on
> Creator.

Thanks for spotting this. The plugin should indeed be marked experimental:

> 2. The manual advises "Do not use the --embedded option for activating
> the emscripten version in the emsdk", but the SDK itself deprecated
> non-embedded, and the latest version doesn't support anything else
> ("embedded mode is now the only mode available").

Indeed. The eventual removal of the "global" emsdk activation mode and the consequent deprecation of the --embedded parameter was announced a long while ago by the emsdk developers. However, I realized only much too late that it finally happened.
In fact, I realized it in the morning of the qtws20-online day right before the streaming of my talk in which I embarrassingly advertise the WebAssembly plugin (incl. --embedded parameter).


> 3. Adding the location to the emsdk/em++ is fine. It's normal that
> Creator is not going to detect where in the disk I got the sources.

This has a history. Qt Creator "asks" the registered compilers for the system include paths and default defines. This happens by calling the compiler with a certain set of parameters. Up to emsdk version 1.38, the em++ and emcc wrapper shell/batch scripts did not support passing these special parameters to the underlying clang compiler. That's why the WebASsembly plugin auto-registered the underlying clang directly, to get at least some data (which was, however, also not 100% correct).

Qt Creator 4.15 registers the em++ and emcc wrapper scripts, and with emsdk 1.39+, the C++ code model seems to work better than ever:

> 4. The Qt 5.15.x WebAssembly version of Qt gets added fine by the
> installer, but it shows the yellow triangle warning, and the message
> about "ABI detection failed".

The binary format of Qt for WebAssembly binaries changed between 5.14 and 5.15, which I also found out much too late. I think the consequence of it is that the Kit device is not automatically detected (but that can be manually adjusted). The detection of the additional "\0asm" format has been added to Qt Creator 4.15.

> 5. When going to the kit tab, if I don't add "wasm-emscripten" to the
> "Qt mkspec" input, then qmake is invoked with "linux-clang" as mkspec,
> and compiles just wrongly.

I assume this is a consequence of the underlying misconfigurations. By default, the "Qt mkspec" field would be empty. Here a screenshot of how a functional WebAssembly Qt Kit looks in 4.15:

> 6. If I don't set EM_CONFIG and point it to the right location where
> the SDK and it's ".emscripten" config is, we don't get the compiler
> working (em++ spits error about missing BINARYEN_ROOT, because it's
> using the one in ~/.emscripten).

A possible workaround is to manually create a ~/.emscripten file which the current plugin expects. Lorn posted a script which generates one for Linux:

> 7. After the last tweak, I can get things built in Creator, but the
> code model chokes on most code, as it can't find anything from the
> standard library (qglobal.h can't include type_traits, so pretty much
> nothing works). Looking at the code model inspector, I see that it
> just doesn't contain any path from the toolchain, so no standard
> library. I tried to add it somewhere, but I did not find where. I
> don't know if it's because of this, but Creator spins at least one CPU
> core constantly while in this state. Switching kit calms it down.

> I've seen that some important issues (points 3 to 6 more or less) seem
> to be addressed in some tickets
> (https://bugreports.qt.io/browse/QTCREATORBUG-24811 and
> https://bugreports.qt.io/browse/QTCREATORBUG-24891 and
> https://bugreports.qt.io/browse/QTCREATORBUG-23741). I don't know if
> point 7 would be fixed as a consequence of the other changes.

The code model issues were already present when emsdk and Qt Creator played well together. TBH, I never tried to elaborate a workaround for that.
The good news is that 4.15, by registering the wrapper scripts and successfully querying includes and defines, is supposed to solve all this. It would however be great to get confirmations from users other than myself if this works :)

> However, I see that the fix version is 4.15. :-(  That's two releases
> away. Is there any fix/workaround for this last issue, or should I
> just (for now) go to the console to do the WebAssembly build/run?

Unfortunately, there is not much more than what you found and what I mentioned that I can suggest as workaround.

You can use a Qt Creator 4.15 snapshot from https://download.qt.io/snapshots/qtcreator/4.15/ and "Link to Qt".

I have my brown paper bag with the WebAssembly logo on it already prepared for the imminent Qt Creator 4.14 release.

> Thank you.

> PS: Writing all this mostly as a brain dump (only 7 requires a
> solution), in case someone else finds these issues and wants a
> solution for the first points, because I did not find much by doing
> searches on the web. I had to go to JIRA to find the meat of it. :)

Thank you for the feedback! And sorry for the most likely unsatisfying current state. The plugin obviously lacks overall "priority" and "interest", but my goal is to at least have very basic, functional Qt for WebAssembly support in Qt Creator.

Best regards,
Alessandro Portale

More information about the Qt-creator mailing list