DracoUnity: Build fails for WebGL on Unity 2022.2 (new Emscripten)
After upgrading to unity 2022.2 my project build fails with the following error:
Library\Bee\artifacts\WebGL\build\debug_WebGL_wasm\build.js: undefined symbol: _ZNSt3__212basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC1ERKS5_ (referenced by top-level compiled C/C++ code)
I’m thinking this is caused by the new Emscripten version
After searching files for the symbol name it seems to originate from the WebGL Plugin “libdracodec_unity.a” ZNSt3__212basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC1ERKS5
\Library\PackageCache\com.atteneder.draco@4.0.2\Runtime\Plugins\WebGL\libdracodec_unity.a (5 hits) Line 6456 Line 12534 Line 13293 Line 14564 Line 15409
Looking for advice on how to fix this. We want to use the new features of this unity version
Unity forum link: https://forum.unity.com/threads/builds-failing-after-upgrading-to-2022-2.1385088/
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 1
- Comments: 26 (5 by maintainers)
Commits related to this issue
- add unity 2022 builds, see https://github.com/atteneder/DracoUnity/issues/55 — committed to E-moko/DracoUnity by GwendalBroudin-Emoko a year ago
Hi folks,
TL;DR: I can give you an immediate workaround right now and we’re working on a convenient long-term solution.
Problem
Native Draco libraries are compiled into WebAssembly via Emscripten. Different versions of Unity use different versions of Emscripten. Not all of them are compatible, so one has to compile the libs with the exact version Unity uses. The lack of Unity version settings on native libraries makes it impossible to provide one package that works across a large range of Unity versions.
What I did so far
In the past I just bumped the major release number, so we ended up with:
I could make 5.x support 2022 and 6.x the upcoming 2023.2, but that has downsides:
Solution
As said, unfortunately Unity does not offer a solution here. What we’ll do is split the WebAssembly binaries into sub-packages. One for each Emscripten version. The main package will contain code, that automatically configures your project, so that you’ll end up with a working built with one click.
This is in the making, but releasing a package properly involves some work and multiple parties. Your patience is appreciated.
Workaround for Unity 2022 and newer
WebGL/2022/*.a
over into the package subfolderRuntime/Plugins/WebGL
Again, sorry for the delay and thanks for your patience.
https://github.com/atteneder/draco/releases/ You can install the latest version which is 2.0.0
@der-hugo I thought about this as well, but we’ve opted for another solution that puts WebGL binaries in a sub-package.
@omidhedayati Most of the times this is related to incorrect use of GIT LFS and thus incorrect binaries. Check if the binary files are actually correct (in size and content).
@RyuuyaS Technically this is done, but formal and legal issues need to be resolved before we release the fixed version. I’m not promises, but I expect it to take 1-2 months.
After installing git’s Draco in the package manager, copy the Runtime/Plugins/x86_64 folder, delete the x86_64 folder of Draco in the local copy, and replace it Sorry, maybe my english is strange.
@atteneder Can confirm your solution works.
The issues I encountered were not caused by DracoUnity, but just manifested there. I was finally able to pin down a threading issue that we reported to Unity.
Great! Good to hear you are working on it, and the temporary fix works for us; we can now build (using 2022.2.21), and the glb’s load up nicely.
@PTC-sradlwimmer Did you try increasing the Initial Memory Size in ‘Player / Publishing Settings’? If it is a large GLTF you are loading it might be due to the heap memory that is unable to expand (on time). We use gltFast and also removed a lot of properties from the shadergraphs used by our dataset models. All the different options in the gltf shaders causes a lot of shader variants to be compiled, and they take up a lot of memory in the webgl build.
Hi Stefan,
Thanks for reporting!
Indeed emscripten seems to have upgraded from 2.0.19 to 3.1.8-git. I’ll try an updated build and if that fixes the problem, I’m going to have to make a new major release with updated binaries.