Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] OCaml 3.05 released
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sven LUTHER <luther@d...>
Subject: [Caml-list] Re: 3.05 and future 3.06 binary compatibility ?
On Thu, Aug 01, 2002 at 02:09:39PM +0200, Xavier Leroy wrote:
> > Will this 3.06 release be compatible with 3.05, or will we have to
> > rebuild all the libraries that were built with 3.05 for 3.06 ?
> > 
> > I know you strongly recommend that libraries are rebuilt for each new
> > ocaml version, but a parsing bug hardly seem to affect binary
> > compatibility.
> 
> It's a type-checking bug, not a parsing bug.  You're correct that
> fixing it is likely not to break binary compatibility.  

And would be versioned 3.05.1 or something such if we had three level
version numbers.

> However, I have bad news for you: it turns out that the .cmi files for
> 3.05 have a different format than those for 3.04, and we forgot to
> change the magic number in .cmi files whose purpose is precisely to
> guard against using a .cmi file in an old format.  (The segfault
> reported by Alexander Voinov on this list was tracked down to such an
> undetected use of an old .cmi file.)  Hence, the magic number will be
> bumped in 3.06, causing 3.05-compiled files to be rejected.

Ok, so this is the reason for the segfault during compile, while using
libraries built with 3.04 ?

I checked the .cm* magic number, and did not find them changed, so i
wondered.

Mmm, if the .cm* magic number is not changed (not because it was
forgotten), does this mean we don't need to rebuild the libraries ?

> I know you will hate me for this, but I really don't see any better
> solution.

Well, no problem for us, debian ocaml packaging policy mandate that each
library be compiled with exactly the same version of the ocaml suite
that is currently used anyway, so we will never be bitten by this.
We use the dependencies to make sure that this never cause problem (for
debian packaged libraries).

BTW, after some discution, we feel that for distributions, a scheme with
two camllib directories would be best, the first being the standard
camllib directoty (/usr/lib/ocaml) where we will put distribution
related stuff (packaged libraries), and the second being
/usr/local/lib/ocaml, or even better /usr/local/lib/ocaml/3.05, where
user installed stuff goes.

I already support this somewhat by putting /usr/lib/ocaml/stublibs and
/usr/local/lib/ocaml/stublibs in ld.conf, but i guess more support from
ocaml would be needed to have this work transparently with the -I +dir
options and other.

What do you think about this ?

> - Xavier Leroy, who also spent a while rebuilding all his libs

Well, the autobuilder handle that for us, but we have to bump the
version number and upgrade the dependencies (which could be automated
with something like the --version patch i sent to you).

> PS.  Your mail had an invalid From address "root@iliana".  

Yes, i was root at my homebox when i wrote this mail, and the address
translation did not kick in.

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners