From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id B92C7BC69 for ; Wed, 21 Nov 2007 10:45:42 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAK+MQ0dQDPIblmdsb2JhbACPMgEBAQEHAggREQc X-IronPort-AV: E=Sophos;i="4.21,445,1188770400"; d="scan'208";a="6031255" Received: from smtp20.orange.fr ([80.12.242.27]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Nov 2007 10:45:42 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2007.orange.fr (SMTP Server) with ESMTP id 346C61C00099 for ; Wed, 21 Nov 2007 10:45:42 +0100 (CET) Received: from [192.168.1.59] (APuteaux-154-1-25-148.w83-199.abo.wanadoo.fr [83.199.80.148]) by mwinf2007.orange.fr (SMTP Server) with ESMTP id E65C21C00092; Wed, 21 Nov 2007 10:45:41 +0100 (CET) X-ME-UUID: 20071121094541943.E65C21C00092@mwinf2007.orange.fr Message-ID: <4743FE39.9000208@frisch.fr> Date: Wed, 21 Nov 2007 10:45:29 +0100 From: Alain Frisch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: viktor tron Cc: Caml Mailing List Subject: Re: [Caml-list] C libs from Ocaml libs References: <8cc3d8520711202343q2951aee2lca188a185b84b511@mail.gmail.com> In-Reply-To: <8cc3d8520711202343q2951aee2lca188a185b84b511@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; frisch:01 frisch:01 libs:01 ocaml:01 libs:01 ocaml:01 ocamlc:01 ocamlc:01 -custom:01 -output-obj:01 stub:01 usr:01 lib:01 libcamlrun:01 stub:01 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 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 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