Linking fmodstudio.bc to Emscripten Build

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!

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.

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.

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!

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.

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

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?

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

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