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.

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

fix(windows): use unicode version of CreateProcess #10212

Merged
merged 1 commit into from
Mar 11, 2024

Conversation

emillon
Copy link
Collaborator

@emillon emillon commented Mar 5, 2024

This updates our spawn vendored version to include janestreet/spawn#58.

Fixes #10180

@emillon emillon mentioned this pull request Mar 5, 2024
15 tasks
@emillon
Copy link
Collaborator Author

emillon commented Mar 5, 2024

@kit-ty-kate can you test this? thanks

@kit-ty-kate
Copy link
Member

Thanks for the ping, i'll do that in a minute

@emillon
Copy link
Collaborator Author

emillon commented Mar 5, 2024

still some issues with the vendoring, I'll ping you when it works, sorry

boot/libs.ml Outdated Show resolved Hide resolved
@emillon
Copy link
Collaborator Author

emillon commented Mar 5, 2024

(TODO: update this PR with upstream dune file which restricts flags to win32)

@emillon
Copy link
Collaborator Author

emillon commented Mar 5, 2024

@kit-ty-kate this is now ready if you want to test it.

@kit-ty-kate
Copy link
Member

I can confirm this fixes the issue. I tried twice with two different unicode characters which was reliably causing problems before and this PR fixes the issue.

Thanks a lot!

@emillon
Copy link
Collaborator Author

emillon commented Mar 5, 2024

I've pushed the bootstrap changes to #10217 to make this a bit simpler.

@emillon
Copy link
Collaborator Author

emillon commented Mar 6, 2024

This seems to work, but TBH I'm not completely sold on passing -DUNICODE as cflags compared to using #define in the stubs. I get that it's a more principled way of doing it, but this brings a bit of complexity in the build instructions and in the bootstrap mechanism.

Copy link
Collaborator

@nojb nojb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (modulo the questions below)

vendor/spawn/src/dune Outdated Show resolved Hide resolved
boot/libs.ml Outdated
Comment on lines 118 to 123
let build_flags =
[ ("win32", [ "-ccopt"; "-D_UNICODE"; "-ccopt"; "-DUNICODE" ])
; ("win64", [ "-ccopt"; "-D_UNICODE"; "-ccopt"; "-DUNICODE" ])
; ("mingw", [ "-ccopt"; "-D_UNICODE"; "-ccopt"; "-DUNICODE" ])
; ("mingw64", [ "-ccopt"; "-D_UNICODE"; "-ccopt"; "-DUNICODE" ])
]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see where this is used?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is used in the bootstrap process. It doesn't read the dune files, so the build flags are read from boot/libs.ml.

@emillon
Copy link
Collaborator Author

emillon commented Mar 11, 2024

@dra27 @nojb I have some questions regarding how consistent we need to be with these C flags. Concretely, we have some C stubs in fswatch_win_stubs that pull windows.h. They're built into a library that's linked into dune, next to spawn. Is it an issue if one library has -DUNICODE and the other one doesn't?

@nojb
Copy link
Collaborator

nojb commented Mar 11, 2024

how consistent we need to be with these C flags.

You can have Unicode-compatible and ANSI-compatible code in the same executable, so there is no requirement perse from that perspective. On the other hand, we very much want to be sure that all our Windows C code is Unicode-compatible. The stubs of the "fswatch" library use "W" (= Unicode-compatible) functions explicitly, which is why we don't need to define UNICODE and _UNICODE when building it, but it would be harmless to do it.

@emillon emillon force-pushed the update-spawn-windows branch 2 times, most recently from 9faef00 to 7fb6e28 Compare March 11, 2024 09:23
@emillon
Copy link
Collaborator Author

emillon commented Mar 11, 2024

Thanks for the confirmation @nojb. Given the previous tests and reviews, I'm merging this.

This does several things:
- update our spawn vendored version to include janestreet/spawn#58
- pick the dune file
- add new build flags for bootstrapping

Fixes ocaml#10180

Signed-off-by: Etienne Millon <me@emillon.org>
@emillon emillon merged commit 6c40cb1 into ocaml:main Mar 11, 2024
25 of 27 checks passed
@emillon emillon deleted the update-spawn-windows branch March 11, 2024 10:13
Leonidas-from-XIV pushed a commit to Leonidas-from-XIV/dune that referenced this pull request Mar 11, 2024
This does several things:
- update our spawn vendored version to include janestreet/spawn#58
- pick the dune file
- add new build flags for bootstrapping

Fixes ocaml#10180

Signed-off-by: Etienne Millon <me@emillon.org>
@dra27
Copy link
Member

dra27 commented Mar 11, 2024

Yes, indeed - pretty much everything should use Unicode versions now (most especially when dealing with the file system). The exception is if you have non-ASCII data (say in a database) which was interpreted using the various ANSI legacy encodings.

Defining _UNICODE and UNICODE is good because it catches accidental use of ANSI functions and can also influence header behaviour (I think that part affects the CRT much more than the Windows headers, given that we don't use TCHAR)

Leonidas-from-XIV added a commit that referenced this pull request Mar 11, 2024
This does several things:
- update our spawn vendored version to include janestreet/spawn#58
- pick the dune file
- add new build flags for bootstrapping

Fixes #10180

Signed-off-by: Etienne Millon <me@emillon.org>
Co-authored-by: Etienne Millon <me@emillon.org>
Leonidas-from-XIV added a commit to Leonidas-from-XIV/opam-repository that referenced this pull request Mar 11, 2024
CHANGES:

### Fixed

- When a directory is changed to a file, correctly remove it in subsequent
  `dune build` runs. (ocaml/dune#9327, fix ocaml/dune#6575, @emillon)

- Fix a problem with the doc-new target where transitive dependencies were
  missed during compile. This leads to missing expansions in the output docs.
  (ocaml/dune#9955, @jonludlam)

- coq: fix performance regression in coqdep unescaping (ocaml/dune#10115, fixes ocaml/dune#10088,
  @ejgallego, thanks to Dan Christensen for the report)

- coq: memoize coqdep parsing, this will reduce build times for Coq users, in
  particular for those with many .v files (ocaml/dune#10116, @ejgallego, see also ocaml/dune#10088)

- on Windows, use an unicode-aware version of `CreateProcess` to avoid crashes
  when paths contains non-ascii characters. (ocaml/dune#10212, fixes ocaml/dune#10180, @emillon)
@anmonteiro
Copy link
Collaborator

anmonteiro commented Mar 11, 2024

This change seems to break compiling dune on 4.14+musl+static. Here's the error message:

dune-x86_64-unknown-linux-musl> In file included from vendor/spawn/src/spawn_stubs.c:19:
dune-x86_64-unknown-linux-musl> /nix/store/bxid93hl5p406haravq2bc189y93c6gp-ocaml+flambda-x86_64-unknown-linux-musl-4.14.1/lib/ocaml/caml/signals.h:97:48: error: unknown type name 'sigset_t'
dune-x86_64-unknown-linux-musl>    97 | CAMLextern int (*caml_sigmask_hook)(int, const sigset_t *, sigset_t *);
dune-x86_64-unknown-linux-musl>       |                                                ^~~~~~~~
dune-x86_64-unknown-linux-musl> /nix/store/bxid93hl5p406haravq2bc189y93c6gp-ocaml+flambda-x86_64-unknown-linux-musl-4.14.1/lib/ocaml/caml/signals.h:97:60: error: unknown type name 'sigset_t'; did you mean 'size_t'?
dune-x86_64-unknown-linux-musl>    97 | CAMLextern int (*caml_sigmask_hook)(int, const sigset_t *, sigset_t *);
dune-x86_64-unknown-linux-musl>       |                                                            ^~~~~~~~
dune-x86_64-unknown-linux-musl>       |                                                            size_t
dune-x86_64-unknown-linux-musl> make: *** [Makefile:52: _boot/dune.exe] Error 2

and the link to a failing job

@anmonteiro
Copy link
Collaborator

Ah, it looks like that has been discovered in opam-ci too: ocaml/opam-repository#25456

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

Successfully merging this pull request may close these issues.

Windows: Error: CreateProcess(): No such file or directory when PATH contains unicode characters
6 participants