The most problematic failure I’ve seen so far is a failure in the base library – which doesn’t show up when you compile it (it builds fine) but when you link against it – so basically all base-depending binaries are broken. For example pcre currently fails to build with the following error message:

- /usr/bin/ld: /app/sandbox/opamstate/4.10.0+trunk/dotopam/4.10.0+trunk/lib/base/libbase_stubs.a(exn_stubs.o): in function `Base_clear_caml_backtrace_pos': - /app/sandbox/opamstate/4.10.0+trunk/dotopam/4.10.0+trunk/.opam-switch/build/base.v0.13.0/_build/default/src/exn_stubs.c:6: undefined reference to `caml_backtrace_pos' - collect2: error: ld returned 1 exit status - File "caml_startup", line 1: - Error: Error during linking

(I believe that the error is known to base developers; it was reported on the OCaml bugtracker last month, and I hope that this will get resolved quickly to un-block base users wishing to test the new version.)

Some amount of C runtime churn went into the release (some is only in trunk), due to both the gradual introduction by @jhjourdan and @stedolan of statmemprof support (not yet completed), a related cleanup of internal asynchronous-callbacks APIs with @gadmm, and some multicore-preliminary PRs, in particular @kayceesrk’s Domain_state PR.

These changes in turn triggers some compatibility issues with C code using compiler internals, some which are due to mistakes in the compiler’s backward-compatibility support (we are gradually fixing those), and some where it’s rather a problem with the user code relying on non-stable internals. Do not hesitate to ask (here or on the compiler bugtracker) if you observe a failure in your code and you are not sure in which of those two categories it falls.