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.
https://git.fedorahosted.org/cgit/fedora-ocaml.git/log/?h=fedora-24-4.02
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:
https://github.com/ocaml/ocaml/pull/225
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
git.fedorahosted.org link above.)
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):
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2741551
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
broken.
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
arches.
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
again:
http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=13...
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.
Any comments?
Rich.
--
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.
http://fedoraproject.org/wiki/MinGW