David Allsopp

Sorry for the slowness, I've at least updated ocaml.5.3.0 to support it (would you be able to test that with omod and down versions which do install to `%{toplevel}%` instead?)....

> But perhaps the emergency fix is to set both `OCAMLTOP_INCLUDE_PATH` and `$OCAML_TOPLEVEL_PATH` in the 5.3 compilers. But it already is? https://github.com/ocaml/opam-repository/blob/aa131f3eda80ed7121debe7582faaf50448bc105/packages/ocaml/ocaml.5.3.0/opam#L27-L33

We should almost certainly change this line in the ocamlfind.1.9.6 and earlier: https://github.com/ocaml/opam-repository/blob/aa131f3eda80ed7121debe7582faaf50448bc105/packages/ocamlfind/ocamlfind.1.9.6/opam#L35 to be `{ocaml:preinstalled && ocaml:version < "5.3.0~~"}` (xref #27253), but this is for system compilers only already?

I think so, yes (we just posted the same analysis on opposite issues!). Setting `OCAMLTOP_INCLUDE_PATH` was already planned, it was just waiting for #27302.

(just preparing the PR)

This doesn't have an easy solution, I'm afraid. There are two parts to it: - The package installation failure I think - as you suggest - is related to symlink...

Hah - I'd forgotten that C11 giveth and C23 taketh away! I've updated that commit to define a `NORETURN` instead (the motivation to keep the caml headers out of the...

@MisterDA - are you able/willing to do a full review?

Thanks, @MisterDA! > * I'd prefer seeing `perror` and `strerror_r` over ad-hoc error messages in the unix path; This changes the behaviour, which is beyond the scope of what's in...

Related issue in the compiler at https://github.com/ocaml/ocaml/pull/12326 (which was solved by https://github.com/ocaml/ocaml/pull/12465). I'm also wondering instead whether we could have a new global variable indicating the result of `getconf LONG_BIT`...