Dune 3.4+ broken in esy on Windows

[phated]

Expected Behavior

Dune 3.4+ should build inside esy on Windows.

Actual Behavior

Dune fails to build with this log:

# esy-build-package: building: @opam/dune@opam:3.4.1
# esy-build-package: pwd: C:\Users\grain\.esy\3\b\opam__s__dune-opam__c__3.4.1-4a143223
# esy-build-package: running: "ocaml" "bootstrap.ml" "-j" "4"
ocamlc -output-complete-exe -w -24 -g -o .duneboot.exe -I boot unix.cma boot/libs.ml boot/duneboot.ml
.\.duneboot.exe -j 4
cd _boot && C:\Users\grain\.esy\3_\i\ocaml-4.14.0-cd77a8d9\bin\ocamlopt.opt.exe -o ..\dune.exe -g -I +threads unix.cmxa threads.cmxa -no-alias-deps -w -49-6 readdir.c wait3_stubs.c xdg_stubs.c spawn_stubs.c dune_stats_stubs.c fsevents_stubs.c inotify_stubs.c pthread_chdir_stubs.c -args mods_list -cclib -lshell32 -cclib -lole32 -cclib -luuid -alert -unstable
otherlibs/xdg\xdg_stubs.c: In function 'dune_xdg__get_known_folder_path':
otherlibs/xdg\xdg_stubs.c:35:9: warning: implicit declaration of function 'SHGetKnownFolderPath'; did you mean 'SHGetFolderPath'? [-Wimplicit-function-declaration]
otherlibs/xdg\xdg_stubs.c:41:38: error: 'WC_ERR_INVALID_CHARS' undeclared (first use in this function); did you mean 'MB_ERR_INVALID_CHARS'?
otherlibs/xdg\xdg_stubs.c:41:38: note: each undeclared identifier is reported only once for each function it appears in
error: command failed: "ocaml" "bootstrap.ml" "-j" "4"

The issues seem to be SHGetKnownFolderPath and WC_ERR_INVALID_CHARS in the xdg stubs.

Reproduction

1. On Windows, create an esy.json with the following:

{
    "dependencies": {
        "ocaml": "4.14.0",
        "@opam/dune": "3.4.1"
    },
    "esy": {
        "build": [
            "dune build -p #{self.name}"
        ]
    }
}

1. Try to build the project by running esy
2. You'll see the same error as posted above

Specifications

• Version of dune (output of dune --version): 3.4.1
• Version of ocaml (output of ocamlc --version) 4.14.0
• Operating system (distribution and version): Windows (Server 2019)

Additional information

• Link to gist with verbose output (run dune with the --verbose flag):

[rgrinberg]

cc @nojb

[nojb]

Hello, which compiler are you using?

[phated]

Hello, which compiler are you using?

Not sure I understand the question, but esy includes a mingw64 installation.

[nojb]

Hello, which compiler are you using?

Not sure I understand the question, but esy includes a mingw64 installation.

Sorry, I meant: "which Windows compiler toolchain are you using", eg mingw64, msvc, etc.

[phated]

👍 Esy builds everything on Windows in a tool they call esy-bash which is a cygwin environment with the mingw64 toolchain installed.

[nojb]

I built Dune with mingw64 and it works, so there is something specific to esy that is at play here. I will try to investigate but it will take me longer because I will need to setup esy first, etc.

[phated]

there is something specific to esy that is at play here.

I don't know, there's definitely something different (Kate mentioned something about headers)

[phated]

@nojb It was suggested by @Et7f3 that I run x86_64-w64-mingw32-gcc --version inside the esy sandbox and this is what I get: x86_64-w64-mingw32-gcc (GCC) 7.4.0

Is there something else you'd like me to search for?

[phated]

I don't understand this enough to know if this stackoverflow is correct but it says #define NTDDI_VERSION 0x06000000 is needed before #include <windows.h> 🤷

[nojb]

@nojb It was suggested by @Et7f3 that I run x86_64-w64-mingw32-gcc --version inside the esy sandbox and this is what I get: x86_64-w64-mingw32-gcc (GCC) 7.4.0

Is there something else you'd like me to search for?

It seems you have an old compiler (Cygwin is currently on GCC 11); perhaps it is the same with the mingw64 headers. Are you able to try with a more recent version? The current mingw64 version in Cygwin is 10.0. Do you have a way to find out what the version of the installed mingw64 package is, in your environment?

[Et7f3]

Hy,
I think esy when it install just take the latest at that point. Can you install on a new box ? And see if cygwin pick gcc10?

[phated]

@nojb I have the ability to get you any information if you send me the commands to run.

@Et7f3 No, esy zips a version of these tools into esy-bash and unzips them when you install. These issues were discovered in CI which installs esy 0.6.12 fresh each time.

[nojb]

@nojb I have the ability to get you any information if you send me the commands to run.

I don't have specific commands to run, but I would try to (re)build esy-bash so that it picks up the latest versions of the mingw64-* packages (they seem to be outdated in the version you are using).

[phated]

I don't have specific commands to run, but I would try to (re)build esy-bash so that it picks up the latest versions of the mingw64-* packages (they seem to be outdated in the version you are using).

This isn't possible. According to @Et7f3, the function in the headers should have existed for 9+ years, so I think this can/should actually be solved in dune.

[nojb]

the function in the headers should have existed for 9+ years,

Where can I see this?

this can/should actually be solved in dune.

Do you have step-by-step instructions to reproduce this problem?

[phated]

Do you have step-by-step instructions to reproduce this problem?

The reproduction in the main issue shows this exact problem. Do you need me to include:

1. Install nodejs + npm
2. Install esy with npm i -g esy

[phated]

All I have is @Et7f3 saying this in the OCaml Discord:

(Just checked the mingw header it was here for 9 years so it shouldn't be linked with april update)

I don't know which header they checked.

[nojb]

Can you check with #6109 and see if it fixes your problem?

[phated]

Thanks! I'll try it out.