[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