WebAssembly.Module doesn't parse at byte 14259: references are not enabled

[ibanezsc]

An error occurred while initializing WASM in Safari(ios14.3), but chrome works fine on Android. Error is as follows:


 failed to asynchronously prepare wasm:CompileError: WebAssembly.Module doesn't  parse at byte 14259: references are not enabled.

thanks for your help.

[kripken]

Hmm, "references" is odd as emscripten doesn't emit anything using reference types. Perhaps the Safari error is confusing, though. Do you compile or link with any -m flags to enable any post-MVP features, like -mnontrapping-fptoint or -msimd128? (theory based on this)

[yangfangfang1204]

i also have a error ,but i don't use -mnontrapping-fptoint or -msimd128 ？ Unhandled Promise Rejection:RuntimeError :abort(CompileError:WebAssembly.Module doesn't parse at byte 4097:references are not enabled ) at jsStackTrace

[yangfangfang1204]

i solve the problem , my compile with -pthread or -flto -flto=full -flto=thin , compile without them ,it is ok in ios_safari

[yangfangfang1204]

But in mac_safari , it also is the error ?

[CodingMarkus]

i solve the problem , my compile with -pthread or -flto -flto=full -flto=thin , compile without them ,it is ok in ios_safari

This is kind of strange. LTO should not have any effect on the linker output other than better optimized code.

The normal workflow of clang/LLVM is:

1. Translate source code to bitcode
2. Optimize bitcode
3. Translate bitcode to CPU instructions
4. Store CPU instructions in object files
5. Combine CPU instructions of all object files into a single binary

With LTO enabled is slightly different:

1. Translate source code to bitcode
2. Optimize bitcode
3. Store bitcode in object files
4. Combine bitcode from all object files
5. Optimize combined bitcode
6. Translate bitcode to CPU instructions
7. Store CPU instructions into a single binary file

The advantage of LTO is that there is a second optimization step (not just 2, but also 5) which allows bitcode to be optimized across object files and not just within a single object file. But the binary produced in the end does not contain bitcode anymore, so no matter if you use LTO or not, you should end up with a binary of the same format, only one is slightly better optimized than the other one.

So to me it sounds like not LTO itself is the problem but some optimization and by not using LTO, you end up with a less optimized binary and this binary does not use some kind of reference that the other binary was using and that the browser does not support.