Re: Clang driver: can target wasm32 but can’t look up symbols?

Ok, thanks for the clarifications. I am after an out-of-the-box solution, so I guess I am out of luck here, unfortunately. :( Alan On Friday, 9 June 2023 at 13:39:28 UTC+12 tli...@google.com wrote: > I’m general I would not expect the standard JIT setup in LLVM to work with > Wasm, even if we

Re: Clang driver: can target wasm32 but can’t look up symbols?

I’m general I would not expect the standard JIT setup in LLVM to work with Wasm, even if we solved this particular problem. Even if you could look up a symbol, you wouldn’t be able to execute it without calling out to the embedder to first compile and instantiate a Wasm module containing the code.

Re: Clang driver: can target wasm32 but can’t look up symbols?

Hi, Correct, when I build my library for *X86* or *AArch64*, I JIT *X86* and *AArch64* code. So, building my library for *wasm32*, I want to JIT *wasm32* code. Regarding your link, yes, I have seen that piece of code when looking for the error message I am getting. So, how can I ensure that a

Re: Clang driver: can target wasm32 but can’t look up symbols?

Hi, Correct, when I build my library for *X86* or *AArch64*, I JIT *X86* and *AArch64* code. So, building my library for *wasm32*, I want to JIT *wasm32* code. Thanks for your pointer, I am going to look into it. Alan On Friday, 9 June 2023 at 12:38:42 UTC+12 s...@google.com wrote: > When yo

Re: Clang driver: can target wasm32 but can’t look up symbols?

When you build for non-wasm platforms are you JIT'ing non-wasm code? This looks like a codegen issue that only affects the wasm backend. The error in question occurs if a code section contains more than one function symbol. In the wasm backend we expect every function to get its own section (i.

Clang driver: can target wasm32 but can’t look up symbols?

Hi, I have a C++ library that compiles some code on the fly using an ORC JIT and it all works fine when my library is built for *X86* or *AArch64*, but not when it is built for *

Re: SDL1 and SDL2

Are you suggesting that we could somehow use upstream GLFW? That seems unlikely since GLFW interacts so closely with input events and the display.. it seems like we would need a specific emscripten of that library. Or are you suggesting we invest in a port to emscripten in the upststram GL