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.

Sign up for GitHub

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

Jump to bottom

Linking error when running with dune utop #34

Open
zshipko opened this issue May 31, 2021 · 3 comments · May be fixed by #36
Open

Linking error when running with dune utop #34

zshipko opened this issue May 31, 2021 · 3 comments · May be fixed by #36

Comments

@zshipko
Copy link
Contributor

zshipko commented May 31, 2021

Here is the linker error when running dune utop in ocaml-rust-starter:

/usr/bin/ld: src/libocaml_rust_starter.a(ocaml_interop-4a398e80f3ca6ceb.ocaml_interop.8eq22uyz-cgu.12.rcgu.o): in function `_ZN3std4sync4once4Once9call_once28_$u7b$$u7b$closure$u7d$$u7d$17h7171c1b9a6fc7898E.llvm.3140953836603515050':
ocaml_interop.8eq22uyz-cgu.12:(.text._ZN3std4sync4once4Once9call_once28_$u7b$$u7b$closure$u7d$$u7d$17h7171c1b9a6fc7898E.llvm.3140953836603515050+0x3b): undefined reference to `caml_startup'
/usr/bin/ld: src/libocaml_rust_starter.a(ocaml_interop-4a398e80f3ca6ceb.ocaml_interop.8eq22uyz-cgu.12.rcgu.o): in function `_ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h59471d095cabe6c5E.llvm.3140953836603515050':
ocaml_interop.8eq22uyz-cgu.12:(.text._ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h59471d095cabe6c5E.llvm.3140953836603515050+0x3b): undefined reference to `caml_startup'
collect2: error: ld returned 1 exit status

For more information: see the original issue
@mrmr1993
Copy link

mrmr1993 commented Aug 5, 2021

This is primarily an issue when compiling native libraries: you can't depend on caml_startup and friends being available if the library will later be linked against an OCaml program (or loaded dynamically, e.g. by dune utop) but is compiled separately first.

In the short term, I'm planning to remove the offending code in a local fork. Longer term, it would be great to see the runtime code as a separate library, and allow arbitrary code to 'claim' access to the OCaml runtime so that e.g. ocaml-rs can use the runtime when its functions are called from an existing runtime as well.

I'm happy to contribute to this effort, if useful.

@tizoc
Copy link
Owner

tizoc commented Aug 5, 2021

@mrmr1993 yes please! The only reason this has not been fixed is that no one has had time to do it, but a solution would be very welcome.

@mrmr1993 mrmr1993 linked a pull request Aug 6, 2021 that will close this issue
Open
@mrmr1993
Copy link

mrmr1993 commented Aug 6, 2021

@tizoc done, see PR #36.

@tizoc tizoc mentioned this issue Aug 15, 2021
Open
@mt-caret mt-caret mentioned this issue Jul 9, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Separate out caml_startup-dependent code into runtime library mrmr1993/ocaml-interop
3 participants
@tizoc @zshipko @mrmr1993