On Sat, Jan 18, 2020 at 1:09 PM Richard W.M. Jones <rjo...@redhat.com> wrote:
>
> OCaml 4.10.0 beta1 was released upstream about a week ago
> (https://bugzilla.redhat.com/show_bug.cgi?id=1673688).  I'm intending
> to build OCaml packages into a side tag starting today, and then
> if it seems to work well integrate it into F32.
>
> The release notes for this are here:
>
>   https://github.com/ocaml/ocaml/blob/4.10/Changes
>
> Please note there are some incompatible changes.  The ones which I
> think may affect Fedora are below (but there are more, please read the
> release notes in full):

How will this change the number of OCaml packages that are already
broken in rawhide? Will it get better or worse with this rebuild?
There seem to be a number of OCaml packages that haven't even been
built with either 4.08 or 4.09 yet.

OCaml packages cause most of the "broken dependencies" in rawhide
right now, and drown out almost everything else:
See: 
https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md

Fabio

>   * #1859, #9117: enforce safe (immutable) strings by removing
>     the -unsafe-string option by default. This can be overridden by
>     a configure-time option (available since 4.04 in 2016):
>     --disable-force-safe-string since 4.08, -no-force-safe-since
>     between 4.07 and 4.04.
>
> I don't intend to enable this option in our build.  If my greps are
> right there is one package (coccinelle) which is still hanging on
> to -unsafe-string.
>
>   In the force-safe-string mode (now the default), the return type of the
>   String_val macro in C stubs is `const char*` instead of
>   `char*`. This change may break C FFI code.
>   (Kate Deplaix)
>
> This will probably affect more packages, but is a trivial
> const-correctness fix.
>
>   * #8713: Introduce a state table in the runtime to contain the global 
> variables.
>     (The Multicore runtime will have one such state for each domain.)
>
>      This changes the name of some internal variables of the OCaml runtime;
>      in many cases <caml/compatibility.h> provides a compatibility macro with
>      the old name, but programs using runtime internals may need to be fixed.
>
> Properly written FFI extensions shouldn't hit this, but I imagine
> there will be some that are affected.  I will try to fix these on a
> case by case basis.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to