Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: 2002-01-03 (14:34)
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:  FAQ:
To unsubscribe, mail  Archives: