How can I build the OCaml executable with bytecode?

[vthemelis]

I tried by:

• Changing the version of the dune language to 3.9
• Adding

(executable
 (name main)
 (modules main)
 (modes byte exe)
 ...)

(ie the byte mode in the main executable stanza of the generated dune file)

Once I try to run the bytecode executable I get the following:

⨯ dune exec ./main.bc                                           16:09:16
File "dune", line 389, characters 7-11:
389 |  (name main)
             ^^^^
Error: File unavailable:
/Users/vas/.opam/4.14.0/lib/errpy/../stublibs/dllffi_ocaml.so

[vthemelis]

This may be due to an incomplete build of errpy. See: facebook/errpy#4

[stroxler]

Interesting - I recently tried to get the debugger working, and I actually didn't run into this problem on the bytecode executable, but I did run into it if I tried to use ocamldebug.

At any rate I agree that a missing dynamically linked library from errpy is probably the root cause, we should try to get that working.

[vthemelis]

I added a first PR for this here: facebook/errpy#5

I'm not sure if this is the right approach for distribution of the binaries but it's a first step. It solves the first stage of the issue for me locally.

The next issue I get is:

◦ dune exec ./main.bc                                           21:20:35
File "dune", line 389, characters 7-11:  
389 |  (name main)
             ^^^^
ld: library not found for -llwt_unix_stubs
clang: error: linker command failed with exit code 1 (use -v to see invocation)
File "_none_", line 1:
Error: Error while building custom runtime system

but I haven't tried to fix this one yet.

I'm also interested in this so that we can eventually be able to run this under ocamldebug which requires a bytecode build.

[vthemelis]

Added this issue to LWT for my second error: ocsigen/lwt#999

I'm not sure if this is macOS specific.

[vthemelis]

The above was a red-herring.

I managed to build this library as bytecode and once grievejia/pyre-ast#7 and facebook/errpy#5 are done I will add a PR to fix this library as well.

I haven't tested how helpful the OCaml debugger is for this codebase yet but it will at least work.

[vthemelis]

Update on this, I managed to run the debugger and it's fairly useful. The issue that I have is that sometimes it might just crash with a segfault (probably related to the unix.fork code). The steps I've had to follow if anyone else is interested are:

• Get Build with dylib grievejia/pyre-ast#7 in a local OPAM pin. The only way I managed to make this consistently work is if passing an absolute path to the libpython.a static library but once you do that it works locally.
• Get Dynamic library for native dependency errpy#5 in an OPAM pin too. The weirdness on this is described on Add instructions for running the Rust build locally errpy#7 and developers of this project are probably already aware of this issue related to mixing Rust/Cargo with OCaml/opam
• Remove -custom from the main dune file (Uses -custom ocaml/dune#2505). Here's the PR to delete this from main: Remove -custom mode from Dune #776
• Build in bytecode (this is done by adding (modes byte) in the main executable stanza.
• Set the DYLD_LIBRARY_PATH (or equivalent on your OS; this is for the latest versions of macOS) to /path/to/pyre-check/source/_build/install/default/lib/stublibs/

This should allow debugging with ocamldebug. I used earlybird as my front-end in VSCode.

Also, note that even though you can get segfaults when breaking in program flow when running in forward mode, I didn't get any segfaults when running in the time-travelling mode of the debugger. (ie running the program until the end and then adding breakpoints and stepping back)