Browse thread
Dynlinking plugins defining the same unit name but with different implementations.
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2010-07-02 (08:08) |
From: | Alain Frisch <alain@f...> |
Subject: | Re: [Caml-list] Re: Dynlinking plugins defining the same unit name but with different implementations. |
On 07/01/2010 09:16 PM, Daniel Bünzli wrote: > Well in fact this looks like dll bug since if the interface of M.test > doesn't match in a/m.cmx and b/m.cmx then a segfault occurs. Something > similar is reported here : > > http://caml.inria.fr/mantis/view.php?id=4839 > http://caml.inria.fr/mantis/view.php?id=4229 > > Is there any fix expected for the final 3.12 ? As this makes plugins > quite an unreliable feature (if you expect your plugins to come from > different sources). Another related bug: http://caml.inria.fr/mantis/view.php?id=4231 This one shows that the same problem (linking modules with the same name several times, but different implementations, thus breaking the type system) can appear in the following situations: - Static linking with ocamlc (no check at all that two modules with the same name are not linked together). - Static linking with ocamlopt (there is a check that the global symbols corresponding to module themselves are unique; but it can be broken with -for-pack and -pack). So the problem is more general than dynlink. (Note: for dynlink, I believe that loading modules in private mode should be safe.) Alain