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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
