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

[Julien Fischer]

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.
> 
> 
> 
>