[
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: | 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: 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