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...
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48) Zack: e la demo dema ? /\ All one has to do is hit the
(15:57:15) Bac: no, la demo scema \/ right keys at the right time
Attachment:
signature.asc
Description: Digital signature