Sam Clegg

Exactly, if you want to use those boost libraries you would need to build them yourself. Generally speaking you cannot use any libraries from the host (e.g. /usr/lib or /usr/local/lib).

Looks like probably an emscripten bug yes. Something to do with the stdin handling most likely. You can repro this without wasmtime or wasmer: ``` $ emcc test.c node ./a.out.js...

I can't seem to reproduce this. Admittedly I simplified the test case a little by adding this main function and running it under node: ``` int main() { EM_ASM({ const...

Yup, it looks like the `if (size == -1) size = undefined;` is probably wrong since the type of size is `size_t` which is an unsigned type.

On which thread is that backtrace running? Since its a mount event then it seems like it would be main browser thread? Perhaps `emscripten_is_main_browser_thread` is not returning the correct value?

This could be tricky.. because we convert `size_t` and pointer values to to JS numbers when they arrive in JS. We have `{{{ POINTER_MAX }}}`, but that is defined as...

Can you capture it in the debugger with the full backtrace. From the name of the function `ofEvent

So that assertion is firing on the main thread, and its correctly detecting some kind of misconfiguration. Perhaps you are trying use sys_lock/sys_unlock from your audio worklet and those APIs...

@juj, what currently happens if you try to use pthread API from wasm workers? Do we have assertions for that of will things fail in odd ways like this?

Just to be clear what is the expected behavior in "wasm workers + pthread" build if a pthread function is called from a wasm worker? Presumably that is undefined behaviour.....