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
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-11-17 (08:20)
From: Matthieu Dubuget <matthieu.dubuget@l...>
Subject: Re: [Caml-list] caml_startup/caml_cleanup : problem with threads
Matthieu Dubuget a écrit :
> - I experience this with B.dll only. Not A.dll. I'm going to narrow
>   the problem by removing functionnalities from B.dll step by
>   step. 
OK. I have the problem as soon as my DLL uses Thread module.

What does caml_startup in this case?

Here is a minimal set of files allowing to produce a problematic DLL.
Do you think there is any problem with this code and the compilation
command lines?
|Callback.register "wait a moment" Thread.delay

|#include <caml/mlvalues.h>
|#include <caml/callback.h>
|static int demo_init_done = 0;
|void demo_init (){
|  char * argv[] = { "argv", NULL};
|  if (!demo_init_done) {
|    caml_startup (argv);
|    demo_init_done = 1;
|  }
|int demo_init_ok (void){  return demo_init_done; }


And the compilations instructions I used (MinGW version)
|gcc -mno-cygwin -O -mms-bitfields -c -I"C:\Program Files\Objective
Caml\lib" "bug_demo_st.c"   
|     or simply:  ocamlopt -c bug_demo_st.c
|ocamlopt.opt -thread -output-obj -o demog.o unix.cmxa threads.cmxa
|gcc -mno-cygwin -Wl,--kill-at -shared -o bug_demo.dll -L"C:\Program
Files\Objective Caml\lib" \
|             demog.o  bug_demo_st.o bug_demo.def  -lunix -lasmrun
-lwsock32 -lthreadsnat -lthreads

> - Why did I said that LabVIEW is not the problem?
>     - Because we reproduced the problem loading and unloadind B.dll in
>       Java.
>     - Because I experienced the problem another way: I did a little C
>       program that load/unload B.DLL and exits. This program was run
>       from an *eshell* emacs session. And after that. I experienced
>       the window error box 
> when calling another program (It was
>       omake).
I was not able to produce any simple test program demonstrating the DLL
unloading problem (yet).

Do you think I should fill a bug report or am I wrong somewhere?