# Utop not working **URL:** \ **Category:** Learning\ **Tags:** utop, opam\ **Created:** [July 3, 2022, 2:38pm UTC](https://discuss.ocaml.org/t/utop-not-working/10126 "2022-07-03T14:38:10Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Lyes\_I](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/lyes_i/32/3838_2.png) [@Lyes\_I](https://discuss.ocaml.org/u/Lyes_I)\ **Post date:** [July 3, 2022, 2:38pm UTC](https://discuss.ocaml.org/t/utop-not-working/10126/1 "2022-07-03T14:38:10Z")
Hi, I installed utop from opam but I am not able to lauch it, here is my error ![image](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/6/6d6de818421dfd3a211482873f1e8278d50e8d70.png) I m on windows, If someone can help 🙂 ---
**Author:** ![nojb](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/nojb/32/519_2.png) [@nojb](https://discuss.ocaml.org/u/nojb)\ **Post date:** [July 3, 2022, 5:18pm UTC](https://discuss.ocaml.org/t/utop-not-working/10126/2 "2022-07-03T17:18:42Z")
Nothing comes to mind at the moment, but just to flesh out the issue description: which toolchain are you using? MSVC or Mingw? 32-bit or 64-bit? Which version of OCaml? How did you build your packages? Cheers, Nicolas ---
**Author:** ![Chimrod](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/chimrod/32/6042_2.png) [@Chimrod](https://discuss.ocaml.org/u/Chimrod)\ **Post date:** [July 4, 2022, 7:19am UTC](https://discuss.ocaml.org/t/utop-not-working/10126/3 "2022-07-04T07:19:33Z")
I have tested on my environment (cygwin/mingw) just after a fresh install (though opam, comming from the [fdopen repo](https://fdopen.github.io/opam-repository-mingw/installation/)) ```nohighlight $ opam install utop The following actions will be performed: ↘ downgrade zed 3.2.0 to 3.1.0 [required by lambda-term] ∗ install lambda-term 3.2.0 [required by utop] ∗ install utop 2.9.2 … ``` Then the same issue: ```auto D:\home\.opam\4.14.0+flambda+mingw64\bin>utop Fatal error: cannot load shared library dlllwt_unix_stubs Reason: flexdll error: cannot relocate uerror RELOC_REL32, target is too far: ffff8009fdb66776 fffffffffdb66776 ``` ---
**Author:** ![kkirstein](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/kkirstein/32/1964_2.png) [@kkirstein](https://discuss.ocaml.org/u/kkirstein)\ **Post date:** [July 4, 2022, 12:22pm UTC](https://discuss.ocaml.org/t/utop-not-working/10126/4 "2022-07-04T12:22:15Z")
This sounds like an issue that had been reported some time ago. Due to a change in the Mingw binutils 64bit Windows builds were broken: ["Cannot relocate" error with flexdll in OCaml for Windows 4.11 (and older versions) · Issue #92 · ocaml/flexdll · GitHub](https://github.com/ocaml/flexdll/issues/92) In the issue `mingw64-x86_64-binutils` version `2.35.2-1` were reported to work. Currently, I am using version `2.38-1` which also seem to be ok. For the newer version of binutils, there was also a constraint on the ocaml version, but I can’t remember that exactly (`4.14.0` should be ok, but I don’t know about the flambda config). ---
**Author:** ![fdopen](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/fdopen/32/452_2.png) [@fdopen](https://discuss.ocaml.org/u/fdopen)\ **Post date:** [July 4, 2022, 3:17pm UTC](https://discuss.ocaml.org/t/utop-not-working/10126/5 "2022-07-04T15:17:13Z")
What’s the output of: ```bash x86_64-w64-mingw32-gcc --version x86_64-w64-mingw32-ld --version ``` Did you compile `4.14.0+flambda+mingw64`,`lwt`, `utop`, etc. with the same versions of gcc/binutils that are currently installed? Or were cygwin packages updated in the meantime? I hope that the problem disappears again when all packages are built with the same versions of gcc/binutils. Otherwise I guess I have to reintroduce the old hack for flexdll, which is still used for msvc64, and leads to other problems… ---
**Author:** ![fdopen](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/fdopen/32/452_2.png) [@fdopen](https://discuss.ocaml.org/u/fdopen)\ **Post date:** [July 4, 2022, 4:48pm UTC](https://discuss.ocaml.org/t/utop-not-working/10126/6 "2022-07-04T16:48:01Z")
Well, looking at the error message again and at [ocaml/unixsupport.h at 4.14 ¡ ocaml/ocaml ¡ GitHub](https://github.com/ocaml/ocaml/blob/4.14/otherlibs/win32unix/unixsupport.h) Why is `CAMLextern` not used inside `unixsupport.h`? ( e.g. [ocaml/unixsupport.h at d2689fced77bd09b4c67fd629cd46ac07740c5f8 ¡ ocaml/ocaml ¡ GitHub](https://github.com/ocaml/ocaml/blob/d2689fced77bd09b4c67fd629cd46ac07740c5f8/otherlibs/win32unix/unixsupport.h#L67) ) @dra27, @nojb? Does the error disappear when it is changed manually? ```bash cp -p "$(opam var lib)/ocaml/caml/unixsupport.h" "$(opam var lib)/ocaml/caml/unixsupport.h.bak" sed -i 's|extern |CAMLextern |g' "$(opam var lib)/ocaml/caml/unixsupport.h" opam reinstall lwt ``` ---
**Author:** ![dra27](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/dra27/32/5294_2.png) [@dra27](https://discuss.ocaml.org/u/dra27)\ **Post date:** [July 4, 2022, 5:35pm UTC](https://discuss.ocaml.org/t/utop-not-working/10126/7 "2022-07-04T17:35:27Z")
> [@fdopen](#): > > Well, looking at the error message again and at [ocaml/unixsupport.h at 4.14 · ocaml/ocaml · GitHub](https://github.com/ocaml/ocaml/blob/4.14/otherlibs/win32unix/unixsupport.h) > Why is `CAMLextern` not used inside `unixsupport.h`? ( e.g. [ocaml/unixsupport.h at d2689fced77bd09b4c67fd629cd46ac07740c5f8 · ocaml/ocaml · GitHub](https://github.com/ocaml/ocaml/blob/d2689fced77bd09b4c67fd629cd46ac07740c5f8/otherlibs/win32unix/unixsupport.h#L67) ) > @dra27, @nojb? When the `__declspec(dllimport)` part was reintroduced for Cygwin, it wasn’t necessary to do it for symbols outside the runtime. IIRC Cygwin’s address space layout not only guarantees that the main executable _will_ be more than 2GiB away from shared libraries, but also guarantees that DLLs will be loaded _within_ the same 2GiB area. I just co-opted that change when binutils 2.35 changed the default base addresses for mingw-w64. I’m struggling to reproduce it “naturally” (i.e. without manually setting DLL base addresses to be a long way apart), but `unixsupport.h` can be updated, naturally. ---
**Author:** ![Chimrod](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/chimrod/32/6042_2.png) [@Chimrod](https://discuss.ocaml.org/u/Chimrod)\ **Post date:** [July 4, 2022, 6:41pm UTC](https://discuss.ocaml.org/t/utop-not-working/10126/8 "2022-07-04T18:41:30Z")
I have recreated a new opam switch ```nohighlight $ opam switch create "4.14.0+flambda+mingw64_for_utop" 4.14.0+flambda+mingw64 ``` Then install utop again and now the issue is gone. Maybe was it caused by a (not so) old previous installation. Anyway, here is the requested output: ```nohighlight $ x86_64-w64-mingw32-gcc --version x86_64-w64-mingw32-gcc (GCC) 11.3.0 ``` ```nohighlight $ x86_64-w64-mingw32-ld --version GNU ld (GNU Binutils) 2.38 ```