Skip to content
This repository has been archived by the owner on Oct 24, 2023. It is now read-only.

lwt's cmis magically available through ocamlfind but not its dll #44

Open
bsansouci opened this issue Aug 13, 2017 · 5 comments
Open

lwt's cmis magically available through ocamlfind but not its dll #44

bsansouci opened this issue Aug 13, 2017 · 5 comments

Comments

@bsansouci
Copy link
Contributor

Right now it seems like I can install reason-cli and get ocamlfind. Also it seems like when I run ocamlfind ocamlc -package lwt.unix -package lwt.ppx with that ocamlfind (and no opam installed at all) it will compile.
That's a bit surprising and a bit annoying, because when I try to run my executable I get a runtime dll loading errors:

Fatal error: cannot load shared library dlllwt-unix_stubs
Reason: dlopen(dlllwt-unix_stubs.so, 138): image not found

The reason seems to be that the env variable CAML_LD_LIBRARY_PATH doesn't point to anything so reason-cli's ocamlfind cannot find the lwt dll. I work around this issue by doing:

export CAML_LD_LIBRARY_PATH=/usr/local/lib/node_modules/reason-cli/rel/3.x.x________________________________________/i/opam_alpha__slash__lwt-2.7.0-234bd21d/lib/lwt

I'm thinking there's two ways to go about this:

  • prevent reason-cli's ocamlfind from compiling with lwt. I'm guessing lwt's just a dependency of something inside reason-cli, and ocamlfind happens to have the right metadata files or env variables to know about lwt's cmi files, which makes it compile. If we make it error that would be great, it'd force people to download opam to get actual lwt and will prevent all sorts of in-between hacks
  • fill up the CAML_LD_LIBRARY_PATH with lwt paths. I like this solution less because it's a bit magical that lwt happens to work but no other opam deps (well in reality anything that reason-cli depends on would work I'm guessing). But I find this solution better than the current situation.

What do you all think?

@jordwalke
Copy link
Member

The ocamlfind in reason-cli isn't meant to be used for anything except debugging reason-cli at the moment. OCamlfind needs to know where stuff is - and so it needs its env variables / config populated correctly. I think that every project should have its own ocamlfind dependency, and its own config that is populated correctly, for that specific project, which will avoid the problem.

OPAM does this for you at the global level which causes some problems (much like the problem you are seeing here). Esy (which reason-cli is based off of) does it at the project level, for your project's specific set of dependencies.

I think we should stop exposing ocamlfind from reason-cli or at least discourage it for anything other than debugging a reason-cli installation. Thoughts?

@bsansouci
Copy link
Contributor Author

@jordwalke Is there any way to call it something other than ocamlfind so that I don't end up accidentally using it? I want to make sure I have a correct opam install so that things don't sometimes work and sometimes not.

If you think we could get away with not shipping it then that solves my problem :)

@jordwalke
Copy link
Member

Yeah, we can realias binaries that are only coincidentally exported to something like reason-cli-ocamlfind. That way they can still be used to debug the installation, but won't conflict.

@bsansouci
Copy link
Contributor Author

Hey sorry I didn't comment on this for a while.
It'd be awesome if we could make this happen

@bsansouci
Copy link
Contributor Author

Heyyyy this hit us again, where the ocamlfind that comes with Reason-cli shadows opam’s ocamlfind which makes it unusable.
Any chance we can get this fixed quickly?

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

No branches or pull requests

2 participants