WASM Example

[azzamsa]

Hi.

Qt now supports compiling to WASM. Are we able to do this with CXX-Qt?
If this is true. I think we need to add a WASM example.

Thanks for CXX-Qt.

[ahayzen-kdab]

None of us have tried yet, but i think it would be interesting to explore in the future.

If a normal CMake Qt project can be built then it should be possible once the right Rust toolchain is picked. Or maybe there is potentially a route with a cargo build too.

[maciek134]

I have a Qt WebAssembly project I'd be interested to integrate Rust into. Starting with a PoC sounds sensible so I'll try to provide an example if nobody beats me to it.

[maciek134]

Small update, Qt 5 seems like too much pain - 5.15 uses emscripten 1.39.8, which uses llvm 11, while rust is now at llvm 15. As I understand it such a big difference is asking for trouble (and I get relocation errors when linking anyway). Downgrading to rust 1.51.0 that used llvm 11 has another set of issues I don't have time to deal with :D

Qt 6 seems much more promising, since 6.4 uses emscripten 3.1.14 with llvm 15 so I'll try that later.

[maciek134]

Based on the qml_minimal example, built with Qt 6.4.2, emscripten 3.1.14 and rust 1.67.0 with wasm32-unknown-emscripten:

Success, but:

I had to use target_link_options(${APP_NAME}_lib INTERFACE "SHELL:-Wl,--whole-archive $<TARGET_FILE:${CRATE}-static> -Wl,--no-whole-archive") instead of "$<LINK_LIBRARY:WHOLE_ARCHIVE,${CRATE}-static>", otherwise CMake complained that

Feature 'WHOLE_ARCHIVE', specified through generator-expression
'$<LINK_LIBRARY>' to link target 'example_qml_minimal', is not supported
for the 'CXX' link language.

Remove QmlImportScanner from Qt components (and register the object in C++) since it's not present there in cross-builds (there is probably a way to include the x86 one but it's almost 4am :)

And (the bad one) I had to comment out the assert_alignment_and_size macro to get cxx-qt-lib to compile, otherwise I get

cargo:warning=src/types/qcolor.cpp:17:1: error: static_assert failed due to requirement 'sizeof(QColor) == (sizeof(unsigned long[2]))' "unexpected QColor size!"
  cargo:warning=assert_alignment_and_size(QColor, alignof(std::size_t), sizeof(std::size_t[2]));
  cargo:warning=^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  cargo:warning=src/types/assertion_utils.h:13:3: note: expanded from macro 'assert_alignment_and_size'
  cargo:warning=  static_assert(sizeof(TYPE) == (SIZE), "unexpected " #TYPE " size!");
  cargo:warning=  ^             ~~~~~~~~~~~~~~~~~~~~~~

  cargo:warning=src/types/qvariant.cpp:27:1: error: static_assert failed due to requirement 'alignof(QVariant) <= (alignof(unsigned long))' "unexpectedly large QVariant alignment!"
  cargo:warning=assert_alignment_and_size(QVariant,
  cargo:warning=^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  cargo:warning=src/types/assertion_utils.h:11:3: note: expanded from macro 'assert_alignment_and_size'
  cargo:warning=  static_assert(alignof(TYPE) <= (ALIGNMENT),                                  \
  cargo:warning=  ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  cargo:warning=src/types/qvariant.cpp:27:1: error: static_assert failed due to requirement 'sizeof(QVariant) == (sizeof(unsigned long[4]))' "unexpected QVariant size!"
  cargo:warning=assert_alignment_and_size(QVariant,
  cargo:warning=^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  cargo:warning=src/types/assertion_utils.h:13:3: note: expanded from macro 'assert_alignment_and_size'
  cargo:warning=  static_assert(sizeof(TYPE) == (SIZE), "unexpected " #TYPE " size!");
  cargo:warning=  ^             ~~~~~~~~~~~~~~~~~~~~~~
  cargo:warning=2 errors generated.

I'll investigate why the assertions fail next, I guess something to do with wasm being 32bit only?

[ahayzen-kdab]

Awesome progress! The CMake issue is related to #442. The alignment issue could be fun with qreal and pointers how they could be 32bit or 64bit (which could cause more fun with ifdefs and manual C++ bridges :-/ ). Seems unfortunate that wasm picks 32bit for some types by default when it has 64bit available :-/

[maciek134]

Re #442 - I'm running CMake 3.25.2, the expression is recognized but for some reason not allowed when compiling with emscripten (the example compiles fine for x86_64)

wasm separates 32bit and 64bit completely, and I'm building for wasm32 since I don't think wasm64-unknown-emscripten even exists in Rust? But that is definitely the issue, assertions expect a pointer size of 8 bytes while it's 4 in wasm32. Since they count basic types, wouldn't it be better to assert byte counts rather than multiples of the pointer size? Unless this verifies an assumption that is made on the Rust side.

[ahayzen-kdab]

Re #442 - I'm running CMake 3.25.2, the expression is recognized but for some reason not allowed when compiling with emscripten (the example compiles fine for x86_64)

Hmm this probably needs discussing in that issue what solution can work everywhere 🤔 or whether there is another way around the WHOLE_ARCHIVE thing (cc @Be-ing ).

wasm separates 32bit and 64bit completely, and I'm building for wasm32 since I don't think wasm64-unknown-emscripten even exists in Rust? But that is definitely the issue, assertions expect a pointer size of 8 bytes while it's 4 in wasm32. Since they count basic types, wouldn't it be better to assert byte counts rather than multiples of the pointer size? Unless this verifies an assumption that is made on the Rust side.

Normally when the Qt types uses pointers internally we have N usize in rust as the size of the struct then in C++ we check that the size matches N size_t. But for QColor it uses a union of ushorts, so comparing usize is probably not correct in this case and should instead be (5 * u16) + u32 + padding.

Are you able to attach all the types that error when compiling so that we can understand if it's all types, or some that aren't quite asserted correctly ?

[maciek134]

Are you able to attach all the types that error when compiling so that we can understand if it's all types, or some that aren't quite asserted correctly ?

Yup, will do after work. At a glance it seems it's only QColor and QVariant, but the compilation might have failed before it got to others.

[ahayzen-kdab]

Are you able to attach all the types that error when compiling so that we can understand if it's all types, or some that aren't quite asserted correctly ?

Yup, will do after work. At a glance it seems it's only QColor and QVariant, but the compilation might have failed before it got to others.

Thanks! That's hopefully good news as those two use unions and other types, but also are ones that we have used size_t to determine the size. When on a 32bit platform the size might be subtly different. When you have time it would be good to know what it thinks the actual size of these types is so then we can work out if we can calculate the size differently or if we need an ifdef + rust cfg for wasm/32bit.

Once things are building we should consider how/if to build for the wasm target in CI 🤔 so that we ensure it keeps building. Building for the Rust target itself seems possible, getting a build of Qt for wasm seems more fun :-)

[maciek134]

For Qt5 there were docker images, I couldn't find one for Qt6 (though I didn't look too long) so I had to register on their website and use the installer. Thankfully I didn't need to recompile Qt itself since the prebuilt wasm32 toolkit is enough. I'll probably make a docker image myself since I prefer to work with it anyway.

[Be-ing]

I had to use target_link_options(${APP_NAME}_lib INTERFACE "SHELL:-Wl,--whole-archive $&lt;TARGET_FILE:${CRATE}-static> -Wl,--no-whole-archive") instead of "$<LINK_LIBRARY:WHOLE_ARCHIVE,${CRATE}-static>", otherwise CMake complained that

Feature 'WHOLE_ARCHIVE', specified through generator-expression
'$<LINK_LIBRARY>' to link target 'example_qml_minimal', is not supported
for the 'CXX' link language.

Considering that manually specifying the linker arguments worked, this seems to only be a limitation of CMake, not the linker for WASM. Could you report this issue upstream on the CMake issue tracker?