From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <d0@wp.pl>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=SPF_FAIL autolearn=disabled 
	version=3.1.3
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
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 9C9B3BC37
	for <caml-list@yquem.inria.fr>; Mon, 12 Oct 2009 14:36:26 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsgBAFK/0krUTWUBkGdsb2JhbACBUZk7AQEBAQkJDAcTBLsKhC0E
X-IronPort-AV: E=Sophos;i="4.44,545,1249250400"; 
   d="scan'208";a="48435104"
Received: from smtp.wp.pl (HELO mx1.wp.pl) ([212.77.101.1])
  by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2009 14:36:26 +0200
Received: (wp-smtpd smtp.wp.pl 28234 invoked from network); 12 Oct 2009 14:36:23 +0200
Received: from pfpleia.if.uj.edu.pl (d0@[149.156.90.26])
          (envelope-sender <d0@wp.pl>)
          by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP
          for <caml-list@yquem.inria.fr>; 12 Oct 2009 14:36:23 +0200
Message-ID: <4AD33F66.4020200@wp.pl>
Date: Mon, 12 Oct 2009 16:38:30 +0200
From: Dawid Toton <d0@wp.pl>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: caml-list@yquem.inria.fr
Subject: Linking mutually dependent modules for fun
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000000 [gZNk]                               
X-Spam: no; 0.00; dependencies:01 ocaml:01 ocaml:01 functors:01 ocaml's:01 mli:01 val:01 mli:01 val:01 endline:01 ocamlopt:01 ocamlopt:01 cmx:01 fixpoint:01 cmx:01 

I often get into trouble of cyclic dependencies when writing in OCaml.
Perhaps, I'm still not enough mentally shifted from poor languages (for
which circular design is quite natural).

Of course OCaml has many tools to deal with this: functors (which, once
introduced, spread like a disease), type variables and generalization
(which sometimes deadly collide with the functorial way) and ugly global
ref cells (which smell).

Why not try some Pascal style then? ;)
The following is what I got when studying OCaml's linking issues:

A.mli: val flip : unit -> unit
A.ml: let flip () = print_string "1"; B.flop ()  let _ = flip ()
B.mli: val flop : unit -> unit
B.ml: let flop () = print_string "0"; A.flip ()
C.ml: let _ = print_endline "C"

Compile:
ocamlopt -c -S A.ml
ocamlopt -c -S B.ml

The resulting .o depends on existing cmx files, so we can reach fixpoint
  by doing it once more:
ocamlopt -c -S A.ml

The new compiled A happens to work with uinitialized B.
Then use some helper module:
ocamlopt -c -S C.ml
ocamlopt -dstartup -ccopt --verbose C.cmx

Modify a.startup.s to call camlA_entry instead of camlC__entry.
as -o startup.o a.out.startup.s

Verbose gcc invocation gave us proper linking command.
Replace
...std_exit.o C.o /...../stdlib.a ...
with just
...std_exit.o A.o B.o /...../stdlib.a ...

And go!

OK, I must admit that I don't know how to get startup code that would
work in general. This one had wrong memory maps and no initialization of
B... anyway it works. :)

Dawid