OCaml 5 rebuild and i686
We're planning to rebuild all the OCaml packages + dependencies with
the new OCaml 5 compiler (https://ocaml.org/releases/5.0.0). This has
a rewritten runtime system, and Jerry James has been doing amazing
work rebuilding everything in a COPR and fixing lots of issues
(https://copr.fedorainfracloud.org/coprs/jjames/OCaml5/).
There are however three issues with i686. Firstly there are some
issues with LTO, possibly solvable. Secondly there no native code
backend for i686. It has been dropped upstream and apparently they
have no plans to re-add it.
(Native code backends for s390x, riscv64 and ppc64le are also dropped
in 5.0, but with plans to add those back in 5.1. They're just taking
their time to port these ones across to the new architecture.)
For i686, my view is we should drop the architecture for OCaml
packages entirely, rather than build only bytecode bindings and try to
fix the LTO problem.
There's a third, very long time problem with OCaml & i686. It has
existed since the beginning. Because of the size of a field in the 32
bit header used to store information about objects, only up to
4 M-word (16 Mbyte) arrays are supported. This is in practice very
restrictive on the type of software you can build with OCaml & i686,
and so I'm sure it never had much serious use.
Note this affects packages such as graphviz, libguestfs, nbdkit,
plplot and brlapi which provide OCaml bindings. We would need to
patch those bindings out with %ifnarch.
Also it affects programs like haxe, z3, coccinelle, coq, hevea,
frama-c and virt-top which would no longer be available for i686 (but
I guess no one is able to run Fedora i686 machines any more, so this
doesn't matter).
Any other objections ...?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit