Linking fmodstudio.bc to Emscripten Build

FMOD Engine
1

Hi, I’m having a problem linking fmodstudio.bc to my emscripten build. It seems like the .bc file may have been targeted for a different architecture than what is required by the latest emcc compiler (v. 1.39.5). I keep getting an error message from the wasm-ld that says -
“Error: fmodstudio.bc: machine type must be wasm32”.

This has happened both in the HTML5 api versions 2.00.06 and 2.00.07. Is there a way to get this working?

Thanks!

2

The .bc files are LLVM bitcode which should not rely on an emscripten version, you may be using the wrong linker option or something similar.

3

If you are running emscripten on your own c code and are trying to combine your bitcode with fmod’s bitcode, there are a bunch of flags that you will need to add, assuming WASM.

For a clue, here is how the fmodstudio.js and .wasm are made from fmod’s bitcode files.

emcc --bind -Os -s EXPORT_NAME="‘FMODModule’" -s MODULARIZE=1 -s FORCE_FILESYSTEM=1 -s EXTRA_EXPORTED_RUNTIME_METHODS="[‘cwrap’,‘setValue’,‘getValue’]" -s WASM=1 -s ALLOW_MEMORY_GROWTH=1 -o fmodstudio.js fmodstudio.bc fmod_reduced.bc

This is getting inserted into the next point release of the docs amongst other info.

4

Hello Brett:
When I attempt to link your fmodstudio.bc into our wasm project, I still get the error listed above:
wasm-ld: error: c:\work\Wasm\studio\lib\bitcode\fmodstudio.bc: machine type must be wasm32
I am using all the build flags shown in your example.

Also, when I execute the exact command line that you provide, I get the same error:
emcc --bind -Os -s EXPORT_NAME="‘FMODModule’" -s MODULARIZE=1 -s FORCE_FILESYSTEM=1 -s EXTRA_EXPORTED_RUNTIME_METHODS="[‘cwrap’,‘setValue’,‘getValue’]" -s WASM=1 -s ALLOW_MEMORY_GROWTH=1 -o fmod.js fmod.bc fmod_bindings.bc
wasm-ld: error: fmod.bc: machine type must be wasm32
wasm-ld: error: fmod_bindings.bc: machine type must be wasm32

Ideally what we need is a simple static library, a .a file, which contains the FMod sdk built directly for WebAssembly bytecode relocatable object files using LLVM.
Or a way to turn the .bc files into a .a or .o file.

Im using emcc version: 1.39.8
FMod version: 2/3/20 2.00.08

Thanks!

5

from what I can see you will have to use 1.38.* , all versions i activated here worked, 1.39.0 produced that error message.

You do not want a .a file, you simply use fmod.js in your js/html code, or you use .bc with emscripten if you are trying to compile your own c code and want to interface the fmod api directly from the C code.

6

https://emscripten.org/docs/getting_started/FAQ.html#why-do-i-get-machine-type-must-be-wasm32-or-is-not-a-valid-input-file-during-linking

7

Thanks for the quick response!

We have a C++ based app that have ported to Wasm. So, it sounds like linking in the .bc files is the best solution.

Downgrading our version of Emscripten did not go well.
We will have to wait till FMod supports Emscripten 1.39.

Are there plans to support the latest version of emscripten?

8

Here is a better description of our situation from our Wasm guy:

In October of 2019 the emscripten SDK deprecated the “fastcomp” build process, which built all WebAssembly code as LLVM intermediate bit code (.bc files) and the linking/final processes converted the desired LLVM bit code into 32-bit WebAssembly byte code. All emscripten releases from 1.39 onward now use the “upstream” build process, where the clang compiler and LLVM tools all work with WebAssembly byte code directory.

Our C++ games are currently being built using the new “fastcomp” process, so when we link with an external SDK, we need those files to be in a WebAssembly format (“wasm32” as .o object files or .a static libraries). However, FMod only provides a pre-built WebAssembly module for JavaScript users and LLVM bit code files, which won’t link with LLVM wasm32 byte code files.

Will Firelight Technologies be releasing an updated FMod SDK that provides the LLVM wasm32 byte code files (presumably as a “.a” static library)?

Reference: https://emscripten.org/docs/compiling/WebAssembly.html#backends

9

We will be releasing builds compatible with the new “upstream” llvm backend soon.

11

Any updates on releasing new builds? At least latest version seems to still output same error

12

At this point it is targeted for the next release, 2.00.09, which should be available around the beginning of May.

13

Hi all, it took some time, but I got 2.00.08 fmodstudio.bc and fmodstudio_bindings.bc asm versions linking with my C++ project.

I’m using 1.39.14 fastcomp emcc, which is the latest fastcomp version as of the date of this post. To clarify, my problem was that I was using the upstream version to compile.

Here are some issues I ran into for anyone else trying to get this to work:

  • This version of emcc doesn’t accept or need the BINARYEN_TRAP_MODE flag according to an Emscripten maintainer. The compiler will throw an error if it’s there.

  • In my html I’m loading the js.mem file with an XMLHttpRequest and then passing the Module into the FMODModule on script load to start main in my project (not sure if this is the standard way).

  • This version of emscripten’s Modules now only accepts a js array of callbacks for “preRun”, so if you try setting the callback directly and get an error that says, “preRun” does not contain function “push”, that’s why.

  • I was running into an “array size was too long” error, and realized I needed to set the -s TOTAL_MEMORY flag to a MB value that’s a multiple of 16 and fits the size of the loaded assets to avoid exceeding the byte array.