From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 77D82BB91 for ; Thu, 20 Jan 2005 09:59:23 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j0K8xMUe024860 for ; Thu, 20 Jan 2005 09:59:22 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA20289 for ; Thu, 20 Jan 2005 09:59:22 +0100 (MET) Received: from smtp12.wanadoo.fr (smtp12.wanadoo.fr [193.252.22.20]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j0K8xLd8024855 for ; Thu, 20 Jan 2005 09:59:21 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1204.wanadoo.fr (SMTP Server) with ESMTP id A152D1C0008E; Thu, 20 Jan 2005 09:59:21 +0100 (CET) Received: from pegasos (AStrasbourg-251-1-59-193.w82-126.abo.wanadoo.fr [82.126.135.193]) by mwinf1204.wanadoo.fr (SMTP Server) with ESMTP id 42AB11C00095; Thu, 20 Jan 2005 09:59:21 +0100 (CET) X-ME-UUID: 20050120085921273.42AB11C00095@mwinf1204.wanadoo.fr Received: from luther by pegasos with local (Exim 4.43) id 1CrY9l-0004IB-7f; Thu, 20 Jan 2005 09:59:09 +0100 Date: Thu, 20 Jan 2005 09:59:09 +0100 To: Jacques Garrigue Cc: sven.luther@wanadoo.fr, caml-list@inria.fr, debian-ocaml-maint@lists.debian.org Subject: Re: [Caml-list] binary compatibility of 3.08.3 Message-ID: <20050120085908.GA16413@pegasos> Mail-Followup-To: Jacques Garrigue , sven.luther@wanadoo.fr, caml-list@inria.fr, debian-ocaml-maint@lists.debian.org References: <20050116133724.GB1467@pegasos> <20050116.082637.115932729.garrigue@math.nagoya-u.ac.jp> <20050116182303.GA32427@pegasos> <20050120.145323.12173481.garrigue@math.nagoya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20050120.145323.12173481.garrigue@math.nagoya-u.ac.jp> User-Agent: Mutt/1.5.6+20040907i From: Sven Luther X-Miltered: at nez-perce with ID 41EF72EA.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41EF72E9.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 wrote:01 binary:01 ocaml:01 bytecode:01 bug:01 ocaml:01 bug-fix:01 compiler:01 usr: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: On Thu, Jan 20, 2005 at 02:53:23PM +0900, Jacques Garrigue wrote: > 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. 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