From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 2E576BC8D for ; Thu, 20 Jan 2005 06:53:50 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0K5rn5c001756 for ; Thu, 20 Jan 2005 06:53:49 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA15271 for ; Thu, 20 Jan 2005 06:53:48 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0K5rkK1001746 for ; Thu, 20 Jan 2005 06:53:48 +0100 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id j0K5riWY003137; Thu, 20 Jan 2005 14:53:45 +0900 (JST) Date: Thu, 20 Jan 2005 14:53:23 +0900 (JST) Message-Id: <20050120.145323.12173481.garrigue@math.nagoya-u.ac.jp> To: sven.luther@wanadoo.fr Cc: caml-list@inria.fr, debian-ocaml-maint@lists.debian.org Subject: Re: [Caml-list] binary compatibility of 3.08.3 From: Jacques Garrigue In-Reply-To: <20050116182303.GA32427@pegasos> References: <20050116133724.GB1467@pegasos> <20050116.082637.115932729.garrigue@math.nagoya-u.ac.jp> <20050116182303.GA32427@pegasos> X-Mailer: Mew version 4.1.53 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41EF476D.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41EF476A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 binary:01 sven:01 luther:01 sven:01 luther:01 binary:01 ocaml:01 bytecode:01 bug:01 ocaml:01 compiler:01 usr:01 lib:01 toploop:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: From: Sven Luther > > 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