Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error loading a no_caml_startup built library in dune utop #162

Open
k0pernicus opened this issue Mar 4, 2025 · 1 comment
Open

Error loading a no_caml_startup built library in dune utop #162

k0pernicus opened this issue Mar 4, 2025 · 1 comment

Comments

@k0pernicus
Copy link

k0pernicus commented Mar 4, 2025

First, thanks to all contributors for your work on ocaml-rs.

I successfully built my OCaml library (static and dynamic) from Rust code, and I wanted to try my Rust code using dune utop.
My function is pretty simple, and I don't initialize or use the OCaml runtime in this function.

As an example, it is not much difficult compared to:

#[ocaml::func]
#[ocaml::sig("unit -> string")]
pub fn process_string() -> &'static str {
    return "something"
}

In order to use my library in dune utop I used the no_caml_startup feature, and I have set the OCAML_INTEROP_NO_CAML_STARTUP environment variable.

The issue is, running dune utop, I have this error each time I call my Rust (to OCaml) function:

thread '<unnamed>' panicked at /Users/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ocaml-1.2.0/src/runtime.rs:43:9:
Rust code that is called from an OCaml program should not try to initialize the runtime.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread '<unnamed>' panicked at library/core/src/panicking.rs:218:5:
panic in a function that cannot unwind
stack backtrace:
   0:        0x1043feb3c - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h6e25c13836847e70
   1:        0x104411db0 - core::fmt::write::h37cdb50ab8af3d55
   2:        0x1043fd1b0 - std::io::Write::write_fmt::hd4c273f34c4c0a33
   3:        0x1043fe9f0 - std::sys::backtrace::BacktraceLock::print::h1df7364dde63dc75
   4:        0x1043ff854 - std::panicking::default_hook::{{closure}}::h646e398272c5759a
   5:        0x1043ff648 - std::panicking::default_hook::hf65fd28e95db7176
   6:        0x1044000d0 - std::panicking::rust_panic_with_hook::hc9e2ec2a12b10e12
   7:        0x1043ffd20 - std::panicking::begin_panic_handler::{{closure}}::h3b6449e2eb83bf4c
   8:        0x1043feff0 - std::sys::backtrace::__rust_end_short_backtrace::h38d85099ddd107a3
   9:        0x1043ffa00 - _rust_begin_unwind
  10:        0x104416824 - core::panicking::panic_nounwind_fmt::hd8d3f0c92bbab643
  11:        0x10441689c - core::panicking::panic_nounwind::hd38337cbf8361018
  12:        0x104416940 - core::panicking::panic_cannot_unwind::h47d96b2bff7532cb
  13:        0x1043e2448 - _process_string
  14:        0x1042a26c8 - _caml_bytecode_interpreter
  15:        0x1042a3d3c - _caml_main
  16:        0x10428a48c - _main
thread caused non-unwinding panic. aborting.
[1]    61513 abort      OCAML_INTEROP_NO_CAML_STARTUP=1 dune utop

I checked in the ocaml-rs code and it seems the panic is done because I use the no_caml_startup feature:

#[cfg(feature = "no-caml-startup")]

Do I have to change something in my build, or my configuration, in order to not initialize twice the runtime?

@k0pernicus
Copy link
Author

For anyone asking why I use the no_caml_startup feature: if I don't use it the code panics each time I try to run dune utop in my test project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant