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] Is Caml a fraud ( especially on Windows )?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-10-18 (16:43)
From: Alessandro Baretta <alex@b...>
Subject: Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

Thaddeus L. Olczyk wrote:
> On Fri, 18 Oct 2002 12:56:17 +0200, Sven Luther
> <> wrote:
> But then why does it call cl.exe?

To support linking with C libraries.

>>Maybe you should try using only ocamlopt.
> But then why does cameleon use ocamlc?
> Obviously you want to use ocamlc when debugging,
> but I would think there are Debug and Release versions in
> the make. If so then why is Debug the default ( and why isn't it in
> the documentation)?

This has nothing to do with debugging: ocamlc compiles to 
bytecode, which is fast and guarantees a very high degree of 
portability; ocamlopt produces native code. This requires an 
assembler and a linker from a C compiler. The linker is 
platform-specific and makes native executables not portable, 
although the code can be recompiled with absolutely no 
differences on all supported platforms.

>>That said, there are a few library which are only bindings to C code
>>(the FFI you spoke about previously) and which need a C compiler. But
>>once they are compiled, you can use them without problems.
> What do you need the compiler for?
> To build the C library or to actually build the bindings?
> This seems to be adding to my rants.

In order to link to C code you must first write special C 
functions called "stubs" (Java might be a good choice as 
your next language, so that you may discover that such 
functions exist elsewhere, too). Stubs are necessary to pass 
data back and forth from caml functions in a way compatible 
with the caml runtime, debugger and calling conventions.

> Ok. But why. IIRC the cygwin stuff you have to compile yourself. (
> Something I am loathe to do, especially since I see some people have
> had problems. )

Very well. If you are unable to use Cygwin get yourself a 
Debian distro and you won't have to compile anything at all. 
Sven is the one who does the job for you.

> I can see that the Win32 port is "crippled".  When I assumed that
> the compile used a C compiler, it made sense--cygwin creates code
> that is significantly slower. But if ocamlopt generates native code
> then the speed of the executables produced should be the same speed in
> both ports. So then why distribute the Win32 port as the main port?

Don't blame the Caml team if Windows is crippled OS. Cygwin 
uses gcc to generate code. So Cygwin code is neither faster 
nor slower than equivalent gcc code under Linux. However, 
Cygwin code is linked with a POSIX emulation library which 
runs on top of the standard Win32 C library and kernel. This 
  is less efficient than linking directly with a POSIX 
conformat c library like glibc.

>>>Am I going to discover that a prepackaged library doesn't work
>>And here is your error, these are _not_ prepackaged libraries.
> No but about nine months ago I tried ocaml very briefly. I had
> a set of programs I had to write which basically encapsulated
> database with little processing. It seemed like the perfect
> opportunity to try out a new language because it involved little
> actual coding. At the time the dbm library was unavaile ( on Linux ).

You want the a library? Then, please, go on and write the 
stubs for it. Everybody will be thankful to you. You wanna 
rant about it. Then go on ranting till you please, but it's 
not going to serve much, either to you or to anybody else.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: