Reference error using JS backend

Hi, I’m working on a port of purescript-halogen to Haskell using JS backend, I got it to a point I can actually run hello world component, but I was hit with a reference error in console when running all.js:

Uncaught ReferenceError: h$baseZCGHCziConcziSynczireportError is not defined
    at new h$Thread (index.js:14342:30)
    at h$main (index.js:15073:11)
    at index.js:87713:1

this identifier is used in the definition of Thread

function h$Thread() {
    this.tid = ++h$threadIdN;
    this.status = (0);
    this.stack = [h$done, 0, h$baseZCGHCziConcziSynczireportError, h$catch_e];
(...)

Has anybody seen such an error? For reference my compiler is ghc-9.8.2 cross-compiled from source.
@hsyl20 sorry for ping but you might know what’s up.

EDIT: for reference the repository is here: https://github.com/Swordlash/haskell-halogen

4 Likes

Seems to be fixed after upgrade to 9.10 release though.

2 Likes

This sounds like a really cool project! Glad you managed to work around the issue :slight_smile:

1 Like

Just posting this here, even though one may argue it’s only tangentally related:

I just tried building the current version of halogen-haskell on an m2 mac, as I would like to play around a bit, and see how it compares to e.g. miso. However, I’m getting the following build error while compiling ‘clock-0.8.4’; one of the dependencies:

# cabal build --project-file=cabal-ghcjs.project  
.... 
Preprocessing library for clock-0.8.4...
emcc: error: unsupported target: arm64-apple-darwin (emcc only supports wasm64-unknown-emscripten and wasm32-unknown-emscripten)
compilation failed

Googling the error gives some errors related to cross compiling c and/or rust code from linux to Mac os. The clock package does seem to contain some c code, but I’m not entirely sure how that is related.

I also tried compiling using ‘emconfigure cabal build …’; as I also had to install ghc-with-js-backend that way. But that didn’t change anything.

system version used:

# uname -a 
Darwin device-30.home 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:19:05 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T8112 arm64
brew info emscripten | head -1 
==> emscripten: stable 3.1.74 (bottled), HEAD
# ghcup list | grep javascript 
..                           
✔✔ ghc   javascript-unknown-ghcjs-9.12.1          base-4.21.0.0   

Does anyone know what is causing the above behaviour and/or how to fix it? I would like to play around with halogen-haskell :D.

Hm have you tried using x86_64 ghc via Rosetta emulation? I also have mac at home, I can try tomorrow if I have time.

However it’s very strange it doesn’t support aarch64-apple-darwin, I’m fairly certain it does

EDIT: I can indeed reproduce

@noinia it seems the only dep using it is extra, I’ll try getting rid of it.

UPDATE: I removed it in 0.7.0 but now exec linking is a problem:

[2 of 2] Linking dist-newstyle/build/javascript-ghcjs/ghc-9.12.1/haskell-halogen-core-0.7.0/x/halogen-core-prototype/build/halogen-core-prototype/halogen-core-prototype.jsexe
cache:INFO: generating system asset: symbol_lists/6b89c863307fc2d9d85dde1425520b867493b976.json... (this will be cached in "/Users/mateusz/emsdk/upstream/emscripten/cache/symbol_lists/6b89c863307fc2d9d85dde1425520b867493b976.json" for subsequent builds)
cache:INFO:  - ok
wasm-ld: error: /var/folders/jn/2d9_j_qx2dq8hv64wftm_3900000gn/T/ghc58635_tmp_0/ghc_tmp_4_2.o: section too large
emcc: error: '/Users/mateusz/emsdk/upstream/bin/wasm-ld -o /var/folders/jn/2d9_j_qx2dq8hv64wftm_3900000gn/T/emscripten_temp__hwgnpor/clibs.wasm -L/Users/mateusz/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten /var/folders/jn/2d9_j_qx2dq8hv64wftm_3900000gn/T/ghc58635_tmp_0/ghc_tmp_4_3.o /var/folders/jn/2d9_j_qx2dq8hv64wftm_3900000gn/T/ghc58635_tmp_0/ghc_tmp_4_2.o /var/folders/jn/2d9_j_qx2dq8hv64wftm_3900000gn/T/ghc58635_tmp_0/ghc_tmp_4_1.o /var/folders/jn/2d9_j_qx2dq8hv64wftm_3900000gn/T/ghc58635_tmp_0/ghc_tmp_4_0.o -lGL-getprocaddr -lal -lhtml5 -lstubs-debug -lnoexit -lc-debug -ldlmalloc -lcompiler_rt -lc++-noexcept -lc++abi-debug-noexcept -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr /var/folders/jn/2d9_j_qx2dq8hv64wftm_3900000gn/T/tmp0w6spb3tlibemscripten_js_symbols.so --strip-debug --export=emscripten_stack_get_end --export=emscripten_stack_get_free --export=emscripten_stack_get_base --export=emscripten_stack_get_current --export=emscripten_stack_init --export=_emscripten_stack_alloc --export=__get_temp_ret --export=__set_temp_ret --export=__wasm_call_ctors --export=_emscripten_stack_restore --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=main --export-if-defined=__main_argc_argv --export-if-defined=fflush --export-table --growable-table -z stack-size=65536 --no-growable-memory --initial-heap=16777216 --no-entry --stack-first --table-base=1' failed (returned 1)
javascript-unknown-ghcjs-ghc-9.12.1: `emcc' failed in phase `Linker'. (Exit code: 1)
HasCallStack backtrace:
  bracket, called at compiler/GHC/Driver/Make.hs:2959:3 in ghc-9.12.1-inplace:GHC.Driver.Make
1 Like

Thanks for investigating, and nice that you managed to avoid the first issue. A shame that linking still fail (I indeed get the same error). The discussion in this github thread seems to suggest the issue may. be that the .o file that it tries linking is malformed. I’m having trouble getting my hands on the .o used in this case, since all of these files are produced in temporary directories that are cleaned up before the build returns. So I’m not sure if that is also the issue in this case. Any insights on how I can get my hands on that file and/or further diagnose the issue are welcome.

My first hunch is we’re using wasm32 and the code section is just too big (over 4MB; I think I saw such limitation for function size). I’m not at home now so can’t check but I think I saw only wasm32 binaries in my emsdk. I also saw this issue but as you mentioned all the files come from temp directories. Here is my ghc output: Darwin linking error · GitHub

I created a GHC issue.

It must indeed have something with the code size as I’m not getting it with smaller examples. First example from my blog worked for instance.

I would like to play around with halogen-haskell

@noinia you can still “play around” since it builds under normal ghc (tested with 9.6-9.10) so you can use language server etc. Obviously you won’t be able to run it in IO bcs that’s guarded by arch(javascript) but still better than nothing :slight_smile: the issues seem above my expertise, best I can think of is setting up a linux github CI that compiles stuff for you and uploads them to some place you can download (or even better, deploys). It’s gonna slow you down but cant think of anything else (other than getting a cheap VPS)

Thanks for reporting the issue, and your help diagnosing it. I might try to see if I can get halogen-haskell trough rugh through jsaddle. For fiddling at round with it that might also suffice.

1 Like

Huh that would be awesome! Let me know if you manage to do it.