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
ocamlopt and *using* DLLs
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-05-24 (06:38)
From: Robert Roessler <roessler@r...>
Subject: Re: [Caml-list] ocamlopt and *using* DLLs
Jacques Garrigue wrote:

> From: Robert Roessler <>
>>I tried this on the beginners list, but may not have been asking the 
>>right question(s)... :)
> Doesn't look like a beginner question...

I had been hoping that the ocamlopt manual was not wrong, and that I 
was just missing something... simple. :)

>>2b) can I in general expect that an app that works well with ocamlc 
>>and a collection of OCaml cma libs and compiled DLLs (LablGTK and 
>>associated runtime) will work with ocamlopt - assuming that I generate 
>>and replace cmo/cma files with cmx/cmxa files?
> Except these linking problems, you can assume identical behaviour.
> If there are significant discrepancies, please report them.

Actually, it looks like Nicolas brings up a large conceptual 
difference... I was at first tempted to say that his points about 
ocamlrun.dll did not apply to my case, but then I realized that my 
DLL, while primarily concerned with interfacing between OCaml and the 
C-land Scintilla editing widget, does in fact call on the OCaml 
runtime for things like string and tuple allocation.

Put a different way, ml_scintilla.dll definitely has a dependence on 
ocamlrun.dll - which logical need would not go away even if I 
repackaged the DLL as a static lib.

So, where (in both a conceptual as well as linking-specific terms) do 
I find the hooks (caml_alloc_string, caml_alloc_tuple, 
caml_named_value etc) into the OCaml runtime when it is embedded in my 
ocamlopt-generated executable?

Robert Roessler