On Fri, Jun 15, 2007 at 10:04:44AM +0100, Stefano Zacchiroli wrote:
On Fri, Jun 15, 2007 at 09:44:32AM +0100, Stefano Zacchiroli wrote:
> > > Still, native code objects can break link time compatibility with
> > > compatible .cmis.
> > I don't understand - why is this?
> I'll try to reproduce the problem in a sandbox...
Ok, here is an example and an explanation:
$ cat a.ml b.ml main.ml
(* a.ml *)
let foo () = 1
(* b.ml *)
let bar () = A.foo () + 1
(* main.ml *)
print_int (B.bar ())
$ # let's build in bytecode and nativecode (with inlining)
$ ocamlc -c a.ml
$ ocamlc -c b.ml
$ ocamlc -o a.byte a.cmo b.cmo main.ml
$ ocamlopt -inline 100 -c a.ml
$ ocamlopt -inline 100 -c b.ml
$ ocamlopt -o a.native a.cmx b.cmx main.ml
$ # now let's change the *implementation* of module A and recompile that module
only
$ sed -i s/1/2/ a.ml
$ ocamlc -c a.ml
$ # relinking in bytecode work, i.e. assumptions over interfaces are respected
$ ocamlc -o a.byte a.cmo b.cmo main.ml
$ # relinking in nativecode fails, i.e. assumptions over implementations are not
respected
$ ocamlopt -inline 100 -c a.ml
$ ocamlopt -o a.native a.cmx b.cmx main.ml
Files b.cmx and a.cmx make inconsistent assumptions over implementation A
The rationale is that with inlining enabled, ocamlopt when building
module B has embedded in it implementations coming from module A. If
that is changed module B needs to be rebuilt as well.
Now: do you have a way to inspect native code objects for extracting
assumptions related to module implementations? Cause we have been so far
able only to extract assumption about interfaces...
OK, I see the point now. I had assumed -- wrongly -- that the hash of
a.cmo would change in this case, but it does not. So we need a
version of ocamlobjinfo which can handle *.cmx files as well.
There is another problem with ocamlobjinfo too. See:
http://groups.google.co.uk/group/fa.caml/msg/f2c3e9e8cfa628b3?hl=en&
In Fedora we have avoided this by having a list of modules in the
standard library which we just ignore (Asttypes, Outcometree and
Cmo_format so far).
Rich.
--
Richard Jones
Red Hat