"dunelongcmd" Linking Error on Windows using ocamlopt

Learning
, ,
1

Hello everyone,
Because Opam now supports Windows I have experimented with moving my Ocaml-Workspaces from WSL into Windows proper. This was successful and on my laptop there was a noticeable improvement to the startup time of Visual Studio Code, which no longer needs to connect to WSL.
Since then I have added additional dependencies in order to try and benefit from parallelism. Now I am getting errors like this:

PS D:\Workspaces\aoc\solutions\2023\1> dune runtest --display=short
Entering directory 'D:\Workspaces\aoc'
File "solutions/2023/1/dune", lines 1-7, characters 0-113:
1 | (library
2 |  (name aoc_2023_1)
3 |  (inline_tests)
4 |  (preprocess
5 |   (pps ppx_jane))
6 |  (modes best)
7 |  (libraries re aoc_std))
    ocamlopt solutions/2023/1/.aoc_2023_1.inline-tests/inline_test_runner_aoc_2023_1.exe (exit 2)
/bin/bash: D:TMPbuild_dc7e34_dunelongcmdb2df95: No such file or directory
** Fatal error: Error during linking

File "caml_startup", line 1:
Error: Error during linking (exit code 2)

There have been no changes to the files in the folder but the library aoc_std now has the additional dependencies and an additional module.
If I change (modes best) to (modes byte) (and therefore use ocamlc instead of ocamlopt) it works just fine.
It seems that by adding the dependencies the (very, very long) ocamlopt invocation crossed some threshold which required creating some temporary file which when referred to had some issue with the Windows file separator.
I am not quite sure whether this is a dune bug, an ocamlopt bug, a powershell bug or if I have something in my PATH which gets unexpectedly called instead of the cygwin equivalent.
I am using the sandboxed (powershell) terminal from the Ocaml Platform extension out of Visual Code Studio. Opam uses its own cygwin installation. I use version 5.2.0 of ocaml and mingw-w64.

Thanks in advance.

2

It looks like something in your build called /bin/bash with a Windows-style path (containing backslashes). You may be able to find out what by looking at the Dune log, _build/log.

Cheers,
Nicolas

1 Like
3

Thanks, that helped.
I apparently have multiple bash.exe on my system and when I changed my PATH environment variable to prioritize the cygwin one, everything works just fine.
The bash which produces the errors is in C:/Windows/System32 and is apparently using WSL.
It is weird that dune logged “/bin/bash” when the used bash wasn’t in a folder called “bin”.

EDIT: No that wasn’t the problem. I added the following to my dune-workspace to remove the suspected problematic bash and use cygwins instead:

(context
 (default
  (paths
   (PATH
    (:standard \ "C:\\windows\\system32" "C:\\WINDOWS\\system32")
    "C:\\Users\\Benjamin\\.opam\\.cygwin\\root\\bin"))))

WIth dune exec -- bash I can see that the “right” bash is found, but I get still the same error. If I move the "C:\\Users\\Benjamin\\.opam\\.cygwin\\root\\bin" before standard everything works and I don’t have to remove from system32 from my PATH. So my problem is still solved, but I don’t know for sure what caused the problem in the first place.

4

I hit this issue today. Added the .cygwin\root\bin to my path (at the top) which corrected it. However, it’d be nice if opam would use the correct bash that it installed. Where could we file an issue?

dune init project’s hello world works fine. But first time you link to a library, you’ll hit this, I think.

5

It is kind of a Dune bug (but Dune is in good company with the trick being used - the flexlink used by Windows OCaml has the same problem with long commands). The intent behind native Windows opam is that you’re actually using native Windows - so the expectation of bash is a flawed part of the legacy which expected the first thing a Windows OCaml user to do being the installation of a Unix environment (i.e. Cygwin) :face_with_peeking_eye:

opam 2.2 is only the start of sorting this out properly - what it has sorted is being able to build and install packages from one of the two native Windows shells (that’s why the internal Cygwin installation is very intentionally not exposed by opam env) but there’s still more work to do (both in opam and other core platform tools) to be able to work on OCaml projects without hitting occasional Unixisms. The workaround from a native shell (cmd/PowerShell) in the meantime is either to install one’s own Cygwin/MSYS2 and use its bash or, as you’ve done, choosing to add the internal Cygwin’s bin directory to PATH. Note that this isn’t a silver bullet - if you’re using a Microsoft Visual Studio switch, for example, it’s very easy to end up breaking ocamlopt’s ability to call the linker.

1 Like