It looks like the emscripten SDK support for the signal-related syscalls is only very rudimentary (see
https://github.com/emscripten-core/emscripten/blob/master/src/library_signals.js). In case of sigwait() that's understandable because it wouldn't fit well into the browser-loop model, since it's not simply possible to yield execution back to the browser loop (which is a problem for any blocking POSIX function), so a sigwait() implementation would probably need to be built around ASYNCIFY (
https://emscripten.org/docs/porting/asyncify.html).
What's a bit strange is that the musl source in emscripten implements sigwait (which indirectly calls the 'syscall' SYS_rt_sigtimedwait), but library_signals.js doesn't at least provide an empty syscall stub for sigtimedwait. This looks like an oversight or TODO to me.
As a workaround Maybe you can provide en empty sigwait() C function (inside an 'extern "C"' { }' if you're in C++) in your own code, which then would be choosen by the linker instead of musl's implementation. This would at least fix the linking problems (but if the library actually calls sigwait this would break of course, a "proper" sigwait() implementation would need to be more advanced and involve ASYNCIFY).