<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title></title> </head> <body> <div name="messageBodySection">Does Mercury need `signal` in the absence of `sigaction`? If so, the porting may not be possible currently since neither of these are implemented for emscripten unfortunately.</div> <div name="messageSignatureSection"> Thank you, <div dir="auto">Patrick</div> </div> <div name="messageReplySection">On Mar 16, 2020, 3:16 AM -0700, Julien Fischer <jfischer@opturion.com>, wrote: <blockquote type="cite" class="spark_quote" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;"> Just realised the replies here weren't going through to the list. Julien. On Sun, 15 Mar 2020, Patrick Henning wrote: <blockquote type="cite" class="spark_quote" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">Ok thats great to hear! I applied the patch and compilation succeeded, which is very encouraging. Unfortunately, there is an issue at run time, within the function “MR_init_conservative_GC” something relating to the Boehm GC has the following error: "GC_is_visible test failed”. I’m not sure whether this is a problem with Boehm GC, supposedly it is working fine with WASM (according to comments on this closed issue: https://github.com/ivmai/bdwgc/issues/163), but I think I will open a new issue on their Github to see if anyone has input on that. Regarding your question about integer size, for WASM, according to the spec integers are 32 bit (via https://webassembly.org/docs/c-and-c++/#platform-features). I believe that the configuration step for Mercury is picking up on this correctly; during config I get the following relevant message: "checking whether int is 32-bit… yes”. This being the case, perhaps it is odd that symbols relating to 64 bit integers are involved in compilation. Patrick On Mar 15, 2020, 6:01 AM -0700, Julien Fischer <jfischer@opturion.com>, wrote: Hi Patrick, The patch is now in rotd-2020-03-15 and also in the latest 20.01.2 beta. Cheers, Julien. On Sat, 14 Mar 2020, Patrick Henning wrote: I see, I’ll try applying that patch then. Will it eventually land in a future release? On Mar 14, 2020, 7:55 PM -0700, Julien Fischer <jfischer@opturion.com>, wrote: Hi Patrick, On Sat, 14 Mar 2020, Patrick Henning wrote: Hello again, I’ve made some progress with this but am still struggling. I was able to successfully carry out the “make" step with grade hlc.gc without errors occurring, but have not been able to run ‘make install’ successfully. For now I am attempting to make do with the results of the “make” step. Currently I am stuck on a linking error: when attempting to do the final step of linking a simple mercury program object file with `emcc -o hello.js hello_init.o hello.o /mercury-srcdist-20.01.1/library/libmer_std.a /mercury-srcdist-20.01.1/runtime/libmer_rt.a /mercury-srcdist-20.01.1/boehm_gc/libgc.a`, I get two errors about symbols “MR_box_int64” and “MR_box_uint64” being undefined. These two symbols are defined in mercury.h, so I would expect them to be present in libmer_rt.a, but examining it with llvm-nm seems to indicate that they are not defined there or in fact in any of the other library files. Can anyone help point me in the direction of what I am missing? Does libmer_rt need to be built in a specific way to ensure that “MR_box_int64” and “MR_box_uint64” are included? No, I think there is some code missing from the runtime. The attached (untested) patch to runtime/mercury.c should address it. Julien. </blockquote> </blockquote> </div> </body> </html>