Re: [Caml-list] C libs from Ocaml libs

[Alain Frisch <alain@frisch.fr>]

viktor tron wrote:
> This is now my third project where an ocaml implementation needs a c 
> binding and I keep on struggling
> with the right build environment.

What you want is a main program in C, with some services provided by 
OCaml code, right?

> what do I do? now more or less according to the manual:
> 
> ocamlc -a <all files> fib.ml <http://fib.ml>
> ocamlc -custom -output-obj -o fib_caml.o fib.cma fib_export.ml
> ocamlc -c fib_stub.c
> cp /usr/local/lib/ocaml/libcamlrun.a fib.a
> ar r fib.a fib_caml.o fib_stub.o
> ranlib fib.a
> 
> or
> 
> ocamlc -a <all files> foo.ml <http://foo.ml>
> ocamlc -custom -output-obj -o foo_caml.o foo.cma foo_export.ml
> ocamlc -c foo_stub.c
> libtool -o libfoo.a foo_caml.o foo_stub.o /usr/local/lib/ocaml/libcamlrun.a
> 
> and then link the c program with foo

Note that you don't need -custom here (-output-obj implies -custom).

> * I know that building on several platforms is always a challange but 
> this is such a simple routine.
> if I have to use random command lines in my Makefile, I run into an 
> autoconf hell.
> is their a truly plantform independent routine to do this?

Well, if your main application is in C, I guess your build system will 
need to know somewhat on which platform it runs.

Anyway, in the current development branch on OCaml, it is possible to 
build a dynamic library that contains the OCaml runtime + arbitrary 
OCaml and C code, in a platform-independent way. This is similar to 
linking a main program, but the result is linked as a DLL.

In your case:

ocamlc -output-obj -o fib.so fib_stub.c fib.cma fib_export.ml

or:

ocamlopt -output-obj -o fib.so fib_stub.c fib.cmxa fib_export.ml

(You can also compile the .c and .ml files separately, of course.)

Cf the test2 and testopt2 targets in:
http://camlcvs.inria.fr/cgi-bin/cvsweb/~checkout~/ocaml/test/outputobj/Makefile

(This is an example of a main program in C#, but the same technique also 
  works for a main program in C. In addition, the example uses the 
Dynlink module, but this is orthogonal to your questions.)

> * can someone explain to me how the how exactly .a file created with 
> .cmxa differ from an archive?
> is it the ocaml sturtup code?

The .a file is an archive. It contains the native code produced by 
ocamlopt from OCaml sources. The .cmxa only contains "meta-information" 
about the library.

> * why does ocamlc have a -custom option and why does ocamlopt does not? 
> do I need the -custom options at all here?

-custom means: build a custom version of the OCaml runtime system with 
custom C libraries and objects linked in. This is used when one doesn't 
want to (or cannot) use dynamically link C libraries (such as 
dllunix.so) is not an option. Without -custom, a main program produced 
by ocamlc only contains OCaml bytecode (and a reference to ocamlrun).

Since executables produced by ocamlopt are native executable, it is 
possible to link C libraries and objects directly. There is no need for 
a special -custom option.

In your case, you don't need -custom (see above).

> * what do I do if I don't want to compile the ocaml runtime into my lib, 
> since they might use several
> of my modules so just link at the end with the runtime lib

Well, if you don't want to compile the ocaml runtime into your lib, just 
  don't do it. Simply create an archive with the .o produced by 
-output-obj and your C code. Or don't create an archive at all and link 
everything directly into your final executable.

See Section 18.7.5 of the OCaml manual.

> * how do I create dynamic libs, dlls for windows?

What do you want to put in your dynamic libs? If you want to create a 
"stand-alone" dll with the OCaml runtime + arbitrary OCaml and C code, 
the new behavior of "-output-obj -o XXX.{so,dll}" is/will be what you want.

> * omake is serious overkill (after hours of reading through the manual, 
> I still don't know how the gtk example is relevant, plus omake creates 
> an extra problem for portability, please correct me if I am wrong)

Quite the contrary, I would say. Portability seems like a very 
compelling reason to adopt omake. It works very nicely under Unix and 
Windows.

> * why are the c object files end in .o irrespective of whether they are 
> byte or native?

Files produced by -output-obj are native objects, even if produced by 
ocamlc (in that case, they contain the bytecode as data, but they really 
are native objects). You can choose the base name you want for the 
output of -output-obj, so it is up to you (or your build system) to 
avoid conflicts.


-- Alain