[m-rev.] [m-dev.] Mercury, Emscripten, and WebAssembly

[Patrick Henning]

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.

Thank you,
Patrick
On Mar 16, 2020, 3:16 AM -0700, Julien Fischer <jfischer at opturion.com>, wrote:
>
> Just realised the replies here weren't going through to the list.
>
> Julien.
>
> On Sun, 15 Mar 2020, Patrick Henning wrote:
>
> > 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 at 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 at 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.
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20200330/76326869/attachment.html>