Re: [Caml-list] binary compatibility of 3.08.3
From: Sven Luther <sven.luther@wanadoo.fr>
> > Binary compatibility as you get it in C is just a hack: you drop some
> > consistency checks, and hope that the user is clever enough to not use
> > incompatible libraries. Ocaml chooses the safe way. This could be made
> > a bit more resilient, particularly for bytecode, but you would still
> > have breakages in the bug fix branch.
>
> What would be nice in this light, would be an exact list of the digests, and
> thus the modules, that changed, so we could only rebuild the
> packages that are actually affected. That said, such behavior is a
> major drawback for using ocaml in real projects, i believe.
Not as simple as that. Actually, I tried comparing digests for the
current stable version and 3.08.2, and here are the differences I get.
You can of course do it yourself.
It is not as bad as I would have expected, which explains why you
could believe that binary compatibility is sometimes kept.
(Actually some work was done in the past to avoid having recompiling
everything after any small change in the compiler)
tet4-lib> find . -name \*.cmi -exec cmp "{}" /usr/local/lib/ocaml/"{}" \;
./toploop.cmi /usr/local/lib/ocaml/./toploop.cmi differ
./ocamldoc/odoc_sig.cmi /usr/local/lib/ocaml/./ocamldoc/odoc_sig.cmi differ
./ocamldoc/odoc_opt.cmi /usr/local/lib/ocaml/./ocamldoc/odoc_opt.cmi differ
./ocamldoc/odoc_dep.cmi /usr/local/lib/ocaml/./ocamldoc/odoc_dep.cmi differ
./ocamldoc/odoc_ast.cmi /usr/local/lib/ocaml/./ocamldoc/odoc_ast.cmi differ
./ocamldoc/odoc.cmi /usr/local/lib/ocaml/./ocamldoc/odoc.cmi differ
./camlp4/ast2pt.cmi /usr/local/lib/ocaml/./camlp4/ast2pt.cmi differ
./camlp4/pa_o.cmi /usr/local/lib/ocaml/./camlp4/pa_o.cmi differ
./camlp4/pa_o_fast.cmi /usr/local/lib/ocaml/./camlp4/pa_o_fast.cmi differ
tet4-lib> find . -name \*.cmx -exec cmp "{}" /usr/local/lib/ocaml/"{}" \;
./camlp4/pr_dump.cmx /usr/local/lib/ocaml/./camlp4/pr_dump.cmx differ
./camlp4/pa_r.cmx /usr/local/lib/ocaml/./camlp4/pa_r.cmx differ
./camlp4/pa_o.cmx /usr/local/lib/ocaml/./camlp4/pa_o.cmx differ
./camlp4/pa_o_fast.cmx /usr/local/lib/ocaml/./camlp4/pa_o_fast.cmx differ
So, any program that extends ocamldoc or accesses the toploop module
must be recompiled.
Concerning camlp4, I'm not expert enough to know whether a change in
the above interfaces has consequences, but you should assume this is
the case.
As of this writing, the .cmx's don't seem to have changed much.
Unfortunately, the above is only about changes in the libraries.
There were also bug fixes in the compiler, which result in slightly
different .cmi's for some programs using classes.
For instance, the GObj module in lablgtk. As a result, anything
depending on lablgtk would have to be recompiled, but you cannot
deduce it from the above listing.
> > You can safely assume that every new release breaks binary compatibility.
> > (I.e. that some digests in the libraries have changed.)
>
> Yep, understood that now, 3.08.2 came as a big surprise though, as we somehow
> expected no binary compatibility change for a bug fix release.
>
> But now we know about it, and i will enable the full-rebuild process for the
> 3.08.3 release, hoping that it will be in time for the debian/sarge release.
The most reasonable thing to do.
If some individuals want to take the risk of not recompiling what
seems to work, this is ok for them, but usually you don't want to do
this in a distribution.
If you're ready to do the checks by hand, there is yet another option.
The binary incompatibilities are not platform dependent. So if you
have a problem with the speed of some platforms, you can just
recompile everything on a single platform, and mark everything which
installs modified files as needing a recompilation on all
platforms. Hopefully, this should be sufficient (at least for binary
compatibility).
Jacques Garrigue
Reply to: