OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)

Richard W.M. Jones rjones at redhat.com
Mon May 21 11:00:23 UTC 2007

Richard W.M. Jones wrote:
> David Woodhouse wrote:
>> On Sat, 2007-05-19 at 17:36 +0100, Richard W.M. Jones wrote:
>>> I suspect it's unlikely that upstream will do (a), ever.  There's a 
>>> technical issue.  OCaml really doesn't have a concept of an ABI.  It 
>>> does a kind of whole-program optimisation where even changes to the 
>>> internal implementation of a library can affect the resulting binary. 
>>> Moreover even if you "fixed" that, any change whatsoever to the 
>>> library's signature or the version of compiler it was built with 
>>> (even bugfix releases which have the same version number) will make 
>>> the library incompatible.
>> Our current package scheme doesn't handle this at all, does it? Should
>> our ocaml-*-devel packages have runtime Requires: on the precise n-v-r
>> of ocaml used to build them?
> Yes definitely.  In fact any other behaviour is broken.  (All packages 
> should have this Requires -- I'm not sure why you elected for just the 
> -devel packages).  Furthermore, if one library or program depends on 
> another library, then it must contain a dependency on the precise n-v-r 
> of the library.
> The only reason I didn't do it for the four packages I just put up for 
> review is that I couldn't work out _how_ to do it in the spec file :-(

Looking at this a bit closer, seems like we need an OCaml version of 
"find-requires" and "find-provides"?

There is a program called objinfo (packaged in Debian as 
"ocamlobjinfo").  This isn't part of our RPM, but it should be.  You can 
get this program by building OCaml from the current SRPM, then:
   cd ~/rpmbuild/BUILD/ocaml-3.09.3
   cd tools
   make objinfo
   cp objinfo ~/bin/ocamlobjinfo

Now, a bit of background first.  When OCaml builds a module, it takes a 
MD5 hash over the interface and some of the internals.  It also stores 
in the module the MD5 hashes of any modules that it depends upon.  At 
link time the MD5 hashes are compared, and the link is only allowed to 
proceed if they match.

You can use ocamlobjinfo to find the hashes of modules (and what they 
depend upon).

For example:

   $ ocamlobjinfo /usr/lib64/ocaml/calendar/calendar.cma

gives output like this (heavily cut down):

   Unit name: Time_Zone
   Interfaces imported:
     71f888453b0f26895819460a72f07493        Pervasives
     1876ce678cfa5a1961fac21850f71efd        Unix
     8d84727c6f398e1a8b710d8161e26479        Time_Zone

This means that the library file calendar.cma contains a module called 
Time_Zone.  Time_Zone depends on two modules from the stdlib (Pervasives 
and Unix) and gives the expected MD5 hashes of those modules.  It also 
gives the MD5 hash of the Time_Zone module itself.  Confusingly the 
hashes of the module and its dependencies are all mixed up... Parsing 
the output of ocamlobjinfo is annoying.

So my first idea was to write a "ocaml-find-requires.sh" script which 
would look at the output of ocamlobjinfo and try to work out which files 
(and therefore RPMs) a library depends upon.  This turned out to be 
quite difficult because of the problem of what if a library is already 
installed.  Anyhow I had (I think) a much better idea ...

How about we store the actual module names and MD5 sums as actual 
provides and requires?  So for example the base ocaml module would provide:


and the ocaml-calendar module would require the above, as well as providing:


(It would still need to depend on the exact n-v-r of the ocaml compiler).

So RPM enforces the exact same dependency requirements as OCaml itself. 
  Hopefully with such a scheme it would be impossible to install 
incompatible OCaml modules, at least not without forcing them.

Attached are two candidate ocaml-find-requires.sh and 
ocaml-find-provides.sh scripts.

$ echo /usr/lib64/ocaml/calendar/calendar.cma | ./ocaml-find-requires.sh
ocaml = 3.09.3-1.fc6

$ echo /usr/lib64/ocaml/calendar/calendar.cma | ./ocaml-find-provides.sh


Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocaml-find-provides.sh
Type: application/x-shellscript
Size: 624 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070521/47018b1d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocaml-find-requires.sh
Type: application/x-shellscript
Size: 783 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070521/47018b1d/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070521/47018b1d/attachment-0002.bin>

More information about the Fedora-packaging mailing list