Re: [Caml-list] Re: Dynlinking plugins defining the same unit name but with different implementations.

[Alain Frisch <alain@frisch.fr>]

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