Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Callback in DLL
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] Callback in DLL
> > If you're building a DLL whose purpose is to be loaded inside
> > ocamlrun, then you should link with ocamlrun.lib, which is an "import
> > library" around the DLL entry points exported by ocamlrun.
> 
> 1) if I only link ocamlrun.lib, it can't find external "local_roots" needed
> in CAMLparamX

You probably forgot to compile your C code with the /MD flag (meaning
"multithreaded DLL").

Explanation: the Win32 dynamic linker cannot cope with shared global
variables, so these need to be accessed by calls to shared functions.
The C compiler generates the calls provided the global variable is
declared "dllimport".  The Caml header files add the proper
declaration provided the _DLL symbol is defined.  The C compiler
defines _DLL if it is invoked with the /MD flag.  End of inference :-)

> so I have to use my caml_init_func (dll entry point) and a modified
> interpreter
> which call the entry point passing the adress of local_roots.

No you don't have to modify anything.  Just read carefully the
makefiles in the system sources and follow what's done there.

> > Of course.  You didn't tell it that you've kept a pointer to "v" in
> > the window data.  So, as far as the GC is concerned, nobody is
> > pointing to "v", so it can be freed.
> 
> Actually , "v" is returned to the caml, and then let-stored. So it is
> referenced.

All right, but the GC also moves live blocks around, so it really
needs to know all the pointers to the block.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr