Re: Policy, location of .cma files in binary packages, and dynlink...

[Stephane Glondu <steph@glondu.net>]

Stefano Zacchiroli wrote:
> > I see OCaml's dynamic loading it this way: in the native world, .cmxs
> > would be like .so (dynamic linking), and .cmx/.a/.cmxa would be like
> > .o/.a (static linking). In the bytecode world, .cmo/.cma play a role in
> > both kinds of linking.
>
> What do you mean with "I see ... this way"? Is that what you would like
> to see in the forthcoming future or what? Assuming so, why are you
> differentiating the final effects of native and bytecode objects?
> Ideally, everything should be linkable dynamically and that should be
> done per default; then, if one really wants, it should be possible to
> statically link, but I would like to see this possibility both for
> native and bytecode world.

I was just trying to give an analogy with C to justify the locations of 
the files. I did not understand what you mean after "Ideally...".

> > I did not think about putting dynlinkable objects in another package.
> > Why not. But what about the native/bytecode duality for dynlinkable
> > objects that there will soon be? I think whatever choice you do, there
>
> Uhm, any pointers that this will actually be the case? I'm aware of some
> works in that direction, but I'm still missing hints that any of them
> will be integrated in OCaml mainline.

By "this", do you mean "dynlinkable native objects"? Let me explain in 
more detail what I mean by "native/bytecode duality", in the context 
where OCaml 3.11 (with natdynlink) is released. A program can be 
compiled both in native code and bytecode (such as Ocsigen), and have an 
extension system using dynamic loading. I am not addressing here the 
problem of making all OCaml programs use shared OCaml libraries whenever 
possible. If that program is compiled in bytecode, it must dynamically 
load bytecode objects. If it is compiled in native code, it must 
dynamically load native code objects. So if we allow such programs to be 
in binary packages in both forms, both forms of the dependant libraries 
should be available.

Native dynamic linking is documented at:

  http://alain.frisch.fr/natdynlink.html

--
Stéphane