WebAssembly build errors

Lime
1

Hi!

Can anybody help with wasm target build, please?..

I installed emscripten and setup webassebly as described here:

Then I rebuilt lime with lime rebuild wasm (rebuilt tools too, just in case)

Then I tried to build an existing html5 project for webassemly target with lime build wasm and got the following errors on linking step (wasm-ld.exe). It looks like the Lime submodules (like Cairo) didn’t compile correctly for webassembly target, but it’s beyond my knowledge :slight_smile:



wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(3d94ed2f_ValuePointer.o): undefined symbol: std::terminate()
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: operator delete(void*)
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: operator new(unsigned long)
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: operator delete(void*)
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: operator new
(unsigned long)
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: operator delete
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: operator new
(unsigned long)
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: operator delete
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: std::terminate()
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: operator delete(void*)
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: __cxa_allocate_exception
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: std::bad_array_new_length::bad_array_new_length()
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: typeinfo for std::bad_array_new_length
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: std::bad_array_new_length::~bad_array_new_length()
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: __cxa_throw
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: operator new(unsigned long)
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(0be4b0ab_CairoBindings.o): undefined symbol: std::terminate()
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(604c9d21_SDLSystem.o): undefined symbol: operator new(unsigned long)
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(604c9d21_SDLSystem.o): undefined symbol: operator delete(void*)
wasm-ld: error: C:/dev/Haxe/haxe/lib/lime/git/ndll/Emscripten/liblime-debug.a(604c9d21_SDLSystem.o): undefined symbol: operator new(unsigned long)
wasm-ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
emcc: warning: link failed with undefined C++ symbols. Try linking with ‘em++’ or passing ‘-sDEFAULT_TO_CXX’
2

I’m seeing the same error on Linux.

This warning seems important:

emcc: warning: link failed with undefined C++ symbols. Try linking with ‘em++’ or passing ‘-sDEFAULT_TO_CXX’

I found this in the emscripten 6.0.6 release notes from August 2026:

DEFAULT_TO_CXX is now disabled by default. This means that em++ is now
required when linking C++ programs, matching the behavior of clang and gcc.
The old behavior is still available using -sDEFAULT_TO_CXX.

As best I can tell, hxcpp is relying on the old behavior because it appears to be configured to use emcc instead of em++.

This likely requires a change in the toolchains/emscripten-toolchain.xml file in hxcpp. However, I’m not sure what exactly needs to change.

3

It looks like Lime’s tools directly calls emcc in a couple of places. We’ll probably need to change that in Lime too.

4

I made a couple of small tweaks to Lime tools, and that seems to be enough to get it working without additional changes to hxcpp.

I was able to successfully compile the PiratePig sample to WebAssembly and run it in my browser.

3 Likes
5

Wow, cool! It was fast, thanks a lot!

Already pulling, will check if it works for me after a coffee :slight_smile:

6

Pirate Pig worked for me too! Got scaling issues though - looks like the game doesn’t respond to the browser window size changes…

7

I’m not surprised if there are bugs like this. The webassembly target is still relatively new and experimental, and so it isn’t as well tested as other targets.

8

Sure, no complains, just noticing :slight_smile:

By the way, I tried Web Assembly build hoping to reduce the executable file size, but it produces much larger files, for example, when I build Pirate Pig for html5 -final, the resulting js is 973Kb, while Web Assembly wasm -final build produces js + wasm with total size of 18.6Mb :sweat_smile:

Is it the expected behavior?

Just in case, I don’t know much about web assembly, just wanted to have a quick optimization :)))

9

Lime’s WebAssembly target uses hxcpp to compile C++. So it’s a lot like you’re running the windows/mac/linux target on the web. This includes compiling our third-party library dependencies, some of which provide similar features to what is already available to HTML/JS in the browser for free (but not necessarily exposed to wasm). So a larger file size is not surprising to me.

If there’s a benefit to using WebAssembly instead of JavaScript, it might be performance. Wasm isn’t as fast as native C++, but it’s pretty close. I haven’t benchmarked Lime/OpenFL specifically, though. If your bottleneck is the GPU rather than the CPU, then it won’t make a huge difference.

10

Thanks for the details! Indeed, I noticed all these libs from project/lib are compiled to objs that then linked to the resulting wasm I suppose.

11

The Lime WebAssembly target is largely unusable. I don’t recommend using this target; why exactly do you need WebAssembly?

12

The Lime WebAssembly target is largely unusable. I don’t recommend using this target; why exactly do you need WebAssembly?

I hoped that Web Assembly build can produce a smaller build compared to hml5 target, but it can’t :slight_smile:

13

Unfortunately, smaller builds are not possible.

14

============= Indeed :smiling_face_with_tear: