Re: [Caml-list] binary compatibility of 3.08.3
On Thu, Jan 20, 2005 at 02:53:23PM +0900, Jacques Garrigue wrote:
> 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.
Nice. Stefano tried something such to some degree to analyse the 3.08.2
breakage.
> It is not as bad as I would have expected, which explains why you
> could believe that binary compatibility is sometimes kept.
Exactly, and the fact that maybe i had to big expectations for the bug-fix
branches, but well.
> (Actually some work was done in the past to avoid having recompiling
> everything after any small change in the compiler)
Cool.
> tet4-lib> find . -name \*.cmi -exec cmp "{}" /usr/local/lib/ocaml/"{}" \;
> ./toploop.cmi /usr/local/lib/ocaml/./toploop.cmi differ
If i remember right, the toploop is not part of the runtime, and only used by
ocamlmktop, right ? No library should depend on it, so there should be no
major problem.
> ./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 ocamldoc and camlp4, the usual culprits. What broke most in 3.08.2 where
the thread module.
> 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.
Ok.
> 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.
Ah, but would those not be detected in the above ? Could you elaborate more
about those changes ?
> 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.
Yep, but once we know lablgtk needs a rebuild, we can travel the dependency
tree from there, no problem.
Actually one could imagine a little tool checking all the existing source
codes for presence of the affected modules. Reusing some code of ocamldep
maybe ?
> > > 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.
Yes, but a huge amount of work in the current state, so if we could avoid it ...
> 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.
Bah.
> 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).
Ah, ok, nice to know.
Friendly,
Sven Luther
Reply to: