Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] Bug in Unix library on Mac?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-01-16 (18:23)
From: Sven Luther <sven.luther@w...>
Subject: Re: [Caml-list] binary compatibility of 3.08.3
On Sun, Jan 16, 2005 at 08:26:37AM -0800, Jacques Garrigue wrote:
> From: Sven Luther <>
> > Well, if binary compatibility could be maintained at least on the bug fix
> > branch, it would be good already. 
> > 
> > But if what Jacques says is true, and the binary compatibility is only broken
> > by the way the diggests are calculated, maybe there may be a
> > solution there ?
> > 
> > Or is the binary-compatibility breakage really needed ? 
> Actually, what I gave is only one possible reason for breakage.
> Another that comes to mind is that .cmx's contain code to be inlined.
> If any file was modified in the standard library (to fix a bug there),
> then there is a good chance that this code changed, and as a result
> the digest will make it binary incompatible.

Oh well.

> 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.

> > Anyway, it would be nice if the breakage would at least be announced in the
> > release documentation. Especially if it doesn't touch all the modules and
> > libraries, as was the case for 3.08.2.
> 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.


Sven Luther