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=1.5 required=5.0 tests=AWL,HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id A858DBC69 for ; Wed, 21 Nov 2007 18:06:09 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIL0Q0dA6aawkmdsb2JhbACCc4xCAQEBAQcCBhMW X-IronPort-AV: E=Sophos;i="4.21,447,1188770400"; d="scan'208";a="19543367" Received: from py-out-1112.google.com ([64.233.166.176]) by mail4-smtp-sop.national.inria.fr with ESMTP; 21 Nov 2007 18:06:08 +0100 Received: by py-out-1112.google.com with SMTP id u52so7513898pyb for ; Wed, 21 Nov 2007 09:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=qpIfhtj1tV0Y0mfwuJy2vWseVbnnniBDDRwM5r2OiTE=; b=d4Tur8NAz0eN2qIFuWYxhrcG8nT4GvAunOGF40l2lhLV3OvYpoynmB6w2kLBCjPvfTD1sWv4nMCjxyqYT53YizVbL5JxGWmdu/cHTUqiZyPKWPlUtuzr0THVYoTNOtr8H/UITNsGzRnNw4QvvgiMDUpluFVbgQUZg4yLb3NXexw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=VR4SqlgzfMT24vFn8L7dakD8OYEVPFZM4RzC5fzd7h0Gez6YYPczhUVsPCktbidW3VizvGISLOssh0G5I5Pun4VZ8v3O21R+prjukSXW2MSFwKtitsmhAWtE/Ytjws97BWMPwcP2/KfYlmWZWVMGBVhC6F9PIC84We3ANeq06JQ= Received: by 10.65.150.18 with SMTP id c18mr17348243qbo.1195664766912; Wed, 21 Nov 2007 09:06:06 -0800 (PST) Received: by 10.65.224.20 with HTTP; Wed, 21 Nov 2007 09:06:06 -0800 (PST) Message-ID: <8cc3d8520711210906k2c8ed0abg6f4305b275cddbf3@mail.gmail.com> Date: Wed, 21 Nov 2007 12:06:06 -0500 From: "viktor tron" To: "Caml Mailing List" Subject: Re: [Caml-list] C libs from Ocaml libs In-Reply-To: <4743FE39.9000208@frisch.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15742_25128464.1195664766905" References: <8cc3d8520711202343q2951aee2lca188a185b84b511@mail.gmail.com> <4743FE39.9000208@frisch.fr> X-Spam: no; 0.00; libs:01 ocaml:01 libs:01 frisch:01 frisch:01 ocaml:01 lib:01 runtime:01 macos:01 testopt:01 camlcvs:01 cvsweb:01 makefile:01 dynlink:01 orthogonal:01 ------=_Part_15742_25128464.1195664766905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 21/11/2007, Alain Frisch wrote: > > 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? Alain, thank you very much for taking your time and clarify things for me. Well, the MAIN program can be anything that can handle a correct C-lib. Actually, I had projects in C++, C, Ruby that called my lib. In fact, my next assignment is a .NET integration so your C# example will be a lifesaver for me I guess. 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. This is super! how is this on MacOS, I recall one of your comment earlier (on this list?) that it doesn't work or something. > 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.) Very cool, I will have a thourough look. > * 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. well, I tried. ar -rs foo_caml.o foo_stub.o but then I get linking errors: gcc -o foo_test.native foo_test.c -L. -lchainfreq_native -L/sw/lib/ocaml -lasmrun /usr/bin/ld: Undefined symbols: _caml_apply2 ... lots of other symbols I guess I am missing something pretty trivial here, so apologies to the savvy. > * 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. and not standalone ones? > * 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. yes, in general omake is super appealing, but (a) every dependency my software relies on discourages/angers users. It is already a pain for people to have the ocaml compiler and a shell already. I know this is another world... (b) I still don't know how it would help automate my problem yet, as I said the gtk example is a serious overkill. On a sidenote to this issue, the rocaml package uses a camlp4 extention to create callback registration and automates the creation of a stub file. (And as far as I understood, omake does something similar). Since most of my callbacks use a pretty simple API (meaning I don't have to deal with conversion of esoteric ocaml types), the whole process could easily be automated and integrated in my build template. Viktor ------=_Part_15742_25128464.1195664766905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 21/11/2007, Alain Frisch <alain@frisch.fr> wrote:
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?

Alain, thank you very much for taking your time and clarify things for me.
Well, the MAIN program can be anything that can handle a correct C-lib.
Actually, I had projects in C++, C, Ruby that called my lib.
In fact, my next assignment is a .NET integration so your C# example will be
a lifesaver for me I guess.

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.

This is super! how is this on MacOS, I recall one of your comment earlier (on this list?)
that it doesn't work or something. 


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.)

Very cool, I will have a thourough look.

> * 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.

well, I tried.
ar -rs foo_caml.o foo_stub.o

but then I get linking errors:

gcc -o foo_test.native foo_test.c -L. -lchainfreq_native -L/sw/lib/ocaml -lasmrun
/usr/bin/ld: Undefined symbols:
_caml_apply2
...
lots of other symbols

I guess I am missing something pretty trivial here, so apologies to the savvy.


> * 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.

and not standalone ones?

> * 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.

yes, in general omake is super appealing, but (a) every dependency my software relies on 
discourages/angers users. It is already a pain for people to have the ocaml compiler and a shell
already. I know this is another world... (b) I still don't know how it would help automate my problem 
yet, as I said the gtk example is a serious overkill.

On a sidenote to this issue, the rocaml package uses a camlp4 extention to create callback registration and automates the creation of a stub file. (And as far as I understood, omake does something similar).
Since most of my callbacks use a pretty simple API (meaning I don't have to deal with conversion of esoteric ocaml types), the whole process could easily be automated and integrated in my build template.

Viktor





------=_Part_15742_25128464.1195664766905--