I got my hands on the library's source code and disabled use of the posix signals. Thanks for the advice, though - this made be update my knowledge on the subject)
ср, 9 дек. 2020 г. в 16:42, Floh <[email protected]>: > 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). > On Wednesday, 9 December 2020 at 08:54:56 UTC+1 [email protected] wrote: > >> And, it turns out compiling those system files it is not as >> straightforward as I thought) So I definitely need a way to tell emscripten >> what I need! >> >> среда, 9 декабря 2020 г. в 12:46:46 UTC+5, Dan Pat: >> >>> Hi. A third-party library I am trying to link in is making use of the >>> "sigwait" function, so I am getting an unresolved reference. By grepping >>> through the emscripten sources I was able to find an implementation of the >>> function in the musl library. While I could just get the file compiled as >>> part of my project, I suspect there is a mechanism for passing this >>> requirement to emscripten so that it compiles what's necessary and puts it >>> in the cache for later reuse. Is there such a mechanism? >>> >> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/d52776e9-3eda-402b-bc23-08306c006e35n%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/d52776e9-3eda-402b-bc23-08306c006e35n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAMb%3DomNL60XRZbuyuHHE7Bc1O4OxwJav2arYaCLgJkAL1Z%3DDJg%40mail.gmail.com.
