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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
