Builds in WASM are failing, seemingly stemming from multiply-defined Qt symbols. WASM builds are special in that they statically link to libraries.
Multiply defined symbols seem to be traceable to the Q_PLUGIN_METADATA macro. Qt only allows one plugin per SO/exe, while static builds would bundle multiple into one target.
One solution would be to make all libraries link statically on all targets. Along the way, I would need to solve the multiple definitions error. But, we are unable to build the libraries statically across the board. Mac seems to depend on shared object files to bundle x86/aarch64 code in the same binary.
As a quick fix, we can change our build system to only create a single UI library. With one top-level UI library, there should be no risk of multiple definition errors.
It is debatably bad software architecture since we are bundling unrelated object files. However, a single library should compile on all targets, which is my current concern. I don't plan on shipping UI updates individually, so improved granularity may not be required.
These changes will likely require trigger a complex merge into main.
Builds in WASM are failing, seemingly stemming from multiply-defined Qt symbols. WASM builds are special in that they statically link to libraries.
Multiply defined symbols seem to be traceable to the
Q_PLUGIN_METADATAmacro. Qt only allows one plugin per SO/exe, while static builds would bundle multiple into one target.One solution would be to make all libraries link statically on all targets. Along the way, I would need to solve the multiple definitions error. But, we are unable to build the libraries statically across the board. Mac seems to depend on shared object files to bundle x86/aarch64 code in the same binary.
As a quick fix, we can change our build system to only create a single UI library. With one top-level UI library, there should be no risk of multiple definition errors.
It is debatably bad software architecture since we are bundling unrelated object files. However, a single library should compile on all targets, which is my current concern. I don't plan on shipping UI updates individually, so improved granularity may not be required.
These changes will likely require trigger a complex merge into main.