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 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
