David Allsopp

Ah, thanks! From opam's perspective, this duplicates ocaml/opam#5784. However, I'm wondering if we should harden something in OCaml itself here (and trying to remember if we've discussed it before)

I can't remember/find whether this has been discussed, but I'm wondering if we should unconditionally tweak the name of the C compiler on macOS builds (in order to stop this...

I haven't checked that it still happens, but especially given that `ocamlopt` calls Cygwin executables (the assembler and the C compiler), I'd be concerned that we may hit the same...

The issue has been fixed upstream (see https://github.com/cygwin/cygwin/commit/579064bf4d408e99ed7556f36a3050c7ee99dee6 🙂)

Not yet - it’s manually installing a pre-release Cygwin DLL… once it’s been released and AppVeyor’s updated, I’ll blow away the head commit and we can merge

Sorry, it stalled on my getting to rebase and update it (which is now done!)

I'm afraid f87f3ed will non-trivially break Jane Street's core-unix; cf. [core_unix/src/core_unix_stubs.c#L1331-L1340](https://github.com/janestreet/core_unix/blob/master/core_unix/src/core_unix_stubs.c#L1331-L1340): ```c #if OCAML_VERSION_MAJOR < 5 #define caml_unix_getsockopt_aux unix_getsockopt_aux #define caml_unix_setsockopt_aux unix_setsockopt_aux #endif extern value caml_unix_getsockopt_aux(char *name, enum option_type ty,...

> Should I keep the change adding the `const` to the `name` parameter, or does that [entail too much breakage](https://github.com/search?q=caml_unix_setsockopt_aux&type=code) for a minor gain? I think that's a good change...

I've put this in the 5.2 milestone, because there is a definite workaround to recover the slowness for ocamldoc. The larger "plan" for this is better executed after the "otherlibs"...

Thank you for grasping these nettles, @OlivierNicole. It's extremely helpful to come with the "fresh pair of eyes" that identifies that the manual is confusing on something _and_ then also...