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

2010-07-05 Thread Alain Frisch
On 07/02/2010 07:48 PM, Daniel Bünzli wrote: Now on Linux 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 2010 i686 GNU/Linux with exactly the same code that know works on osx and ocaml 3.12 from svn. I get the following problem when running my test program. error loading shared

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

2010-07-05 Thread Daniel Bünzli
Could you double-check that you do not mix files compiled with different versions? Yes, that's impossible it was on a clean system. Here's another error I get in another example : error loading shared library: ...: undefined symbol: caml_young_ptr Is the whole runtime system missing to them ?

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

2010-07-05 Thread Alain Frisch
On 07/02/2010 07:48 PM, Daniel Bünzli wrote: I tried to add /usr/local/lib/ocaml to LD_LIBRARY_PATH but without success. Any hint ? Is that a bug or am I missing something ? As a side node , you should also always link the main program with -linkall (to make sure all the modules that plugins

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

2010-07-02 Thread Alain Frisch
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

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

2010-07-02 Thread Daniel Bünzli
(Note: for dynlink, I believe that loading modules in private mode should be safe.) No, at least not in 3.12.0+beta1. Daniel ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives:

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

2010-07-02 Thread Alain Frisch
On 07/02/2010 10:27 AM, Daniel Bünzli wrote: (Note: for dynlink, I believe that loading modules in private mode should be safe.) No, at least not in 3.12.0+beta1. Ah yes, sorry, I did not ready your original post carefully enough. I think the problem is that dlopen is called (in

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

2010-07-02 Thread Alain Frisch
On 07/02/2010 10:40 AM, Alain Frisch wrote: I'll try to apply a fix. I've committed a tentative fix (version/3.12 on the SVN repository). Can you try it and see if it solves your problem under Mac OS ? Alain ___ Caml-list mailing list.

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

2010-07-02 Thread Daniel Bünzli
Can you try it and see if it solves your problem under Mac OS ? It does. Thanks for the fix. Btw. dynlink with first class modules is cool. Best, Daniel ___ Caml-list mailing list. Subscription management:

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

2010-07-02 Thread Daniel Bünzli
Now on Linux 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 2010 i686 GNU/Linux with exactly the same code that know works on osx and ocaml 3.12 from svn. I get the following problem when running my test program. error loading shared library:

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

2010-07-01 Thread Daniel Bünzli
Is that expected behaviour ? That looks like dll hell. 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