[Fedora-packaging] Re: native code incompatibilities vs byte code incompatibilities
Richard Jones
rich at annexia.org
Fri Jun 15 10:02:31 UTC 2007
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
More information about the packaging
mailing list