Right now mono-aot-cross is built with llvm 9.0.x(+mono patches) from packages produced out of https://github.com/dotnet/llvm-project. Then the bitcode the mono-aot-cross produces is consumed by the llvm12.0.x bundled with emsdk. This currently works because the 9.x vs 12.x bit code we product has remained compatible but we should aim to use the same llvm version across the entire toolchain and avoid breakage if that changes.
Emscripten uses a fairly stock llvm build now. It looks like the packaging parts happen
as part of https://github.com/WebAssembly/waterfall/blob/master/src/build.py
But it doesn't look like there is enough there to compile the cross compilers.
Since the browser cross compiler doesn't actually need the mono patches one possibility is that we could start producing llvm 12.0.x builds along side the 9.0.x builds in dotnet/llvm-project without forward porting the patches and start using those versions for the browser mono-aot-cross.
Right now mono-aot-cross is built with llvm 9.0.x(+mono patches) from packages produced out of https://github.com/dotnet/llvm-project. Then the bitcode the mono-aot-cross produces is consumed by the llvm12.0.x bundled with emsdk. This currently works because the 9.x vs 12.x bit code we product has remained compatible but we should aim to use the same llvm version across the entire toolchain and avoid breakage if that changes.
Emscripten uses a fairly stock llvm build now. It looks like the packaging parts happen
as part of https://github.com/WebAssembly/waterfall/blob/master/src/build.py
But it doesn't look like there is enough there to compile the cross compilers.
Since the browser cross compiler doesn't actually need the mono patches one possibility is that we could start producing llvm 12.0.x builds along side the 9.0.x builds in dotnet/llvm-project without forward porting the patches and start using those versions for the browser mono-aot-cross.