OCaml is a statically-safe programming language derived from ML which
compiles to very fast native code. It contains native code backends
for most architectures (all Fedora primary & secondary arches except
s/390x in fact).
Currently Fedora downstream carries two non-upstream backends:
For ppc64 (big endian), a backend was written many years ago by David
Woodhouse and was upstream for a time, but was dropped when the
PlayStation 3 stopped supporting Linux. For ppc64le (little endian /
POWER8) IBM's Michel Normand contributed a native code backend last
year. The upstream project always carried a ppc (32 bit) backend, but
we didn't use it and it's not very interesting for us.
Red Hat and IBM have provided help and loaned equipment to the
upstream project, and as a result upstream have now added ppc64 and
ppc64le backends. This work was merged at the end of August. These
backends were inspired by the Red Hat & IBM work but are not
derivatives. For details see:
So what I want to do is add the new backends [actually it's a single,
combined and extended ppc/ppc64/ppc64le backend] to Fedora Rawhide,
and drop our non-upstream backends.
I have so far cherry-picked the merge commit on top of our Fedora
OCaml tree, and I have dropped the downstream ppc64/ppc64le commits
from our tree. (This is not pushed yet so doesn't appear in the
I have tested it on ppc64le to check that the compiler compiles
itself. A scratch build of the compiler with the new backend is here
(I reserve the right to make further changes, this is just a
preliminary test build):
I used this to compile some ocaml-* packages on ppc64le, with -- it
has to be said -- mixed results. There are two compiler bugs
revealed. This compiler won't be able to compile all the ocaml-*
packages on POWER. However because of the depth of dependencies, I
cannot easily do scratch builds to find out which packages will be
Hence I'd like to do a full rebuild, again, to see what breaks. This
*shouldn't affect primary architectures at all*, but will probably
leave some broken ocaml-* packages on the ppc64/ppc64le secondary
We've actually done two complete rebuilds during the F24 development
cycle already, which in a way is good because it means I know how long
it should take, and I'm confident that the scripts I use will work
So I'm pretty confident the primary arch rebuild will go fine, since
it's not affected by any of the above changes - it's basically just a
release bump. We don't even need to use a side tag for this because
the "old" and "new" packages can be mixed on x86 - they are the same.
The plan for ppc64/ppc64le would then be to fix the bugs revealed in
the rebuild with upstream help.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.